Re: [PATCH 1/3] ring-buffer: Add uname to match criteria for persistent ring buffer

From: Steven Rostedt
Date: Tue Dec 17 2024 - 14:43:52 EST


On Tue, 17 Dec 2024 11:38:00 -0800
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Tue, 17 Dec 2024 at 11:01, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
> > But instead, I'll replace the text/data_deltas with a kaslr offset (it will
> > only be exported if the trace contains data from a previous kernel so not
> > to export the current kaslr offset).
>
> Right - never export the KASRL offset for the *current* kernel, but
> the same interface that exports the "previous kernel trace data" can
> certainly export the KASLR for that previous case.

But this will be future work and not something for this merge window, as
it's more of a feature. The only fix is to add that print_field() code, and
the patch series that removes trace_check_vprintf() (which fixes a
different bug).

>
> > Then, on our production systems, we'll save the meta data of the events we
> > enable (this can include module events as well as dynamic events) and after
> > a crash, we'll extract the data along with the saved data stored on disk,
> > and be able to recreate the entire trace.
>
> Yes. And if you save the module names and load addresses, you can now
> hopefully sort out things like %s (and %pS) from modules too.
>
> Although maybe they don't happen that often?

Actually, they do appear a bit. As the kmalloc trace event records the call
sites that do allocation and many of them are in module code.

-- Steve