Re: [PATCH v5 05/13] module: Add printk formats to add module build ID to stacktraces

[Stephen Boyd <swboyd@chromium.org>]

Quoting Andy Shevchenko (2021-04-21 04:49:33)
> On Tue, Apr 20, 2021 at 02:49:55PM -0700, Stephen Boyd wrote:
> > Let's make kernel stacktraces easier to identify by including the build
> > ID[1] of a module if the stacktrace is printing a symbol from a module.
> > This makes it simpler for developers to locate a kernel module's full
> > debuginfo for a particular stacktrace. Combined with
> > scripts/decode_stracktrace.sh, a developer can download the matching
> > debuginfo from a debuginfod[2] server and find the exact file and line
> > number for the functions plus offsets in a stacktrace that match the
> > module. This is especially useful for pstore crash debugging where the
> > kernel crashes are recorded in something like console-ramoops and the
> > recovery kernel/modules are different or the debuginfo doesn't exist on
> > the device due to space concerns (the debuginfo can be too large for
> > space limited devices).
> > 
> > Originally, I put this on the %pS format, but that was quickly rejected
> > given that %pS is used in other places such as ftrace where build IDs
> > aren't meaningful. There was some discussions on the list to put every
> > module build ID into the "Modules linked in:" section of the stacktrace
> > message but that quickly becomes very hard to read once you have more
> > than three or four modules linked in. It also provides too much
> > information when we don't expect each module to be traversed in a
> > stacktrace. Having the build ID for modules that aren't important just
> > makes things messy. Splitting it to multiple lines for each module
> > quickly explodes the number of lines printed in an oops too, possibly
> > wrapping the warning off the console. And finally, trying to stash away
> > each module used in a callstack to provide the ID of each symbol printed
> > is cumbersome and would require changes to each architecture to stash
> > away modules and return their build IDs once unwinding has completed.
> > 
> > Instead, we opt for the simpler approach of introducing new printk
> > formats '%pS[R]b' for "pointer symbolic backtrace with module build ID"
> > and '%pBb' for "pointer backtrace with module build ID" and then
> > updating the few places in the architecture layer where the stacktrace
> > is printed to use this new format.
> > 
> > Example:
> 
> Please, shrink the example to leave only meaningful lines.
> 
> Why, e.g., do we need to see register dump, is it somehow different?

Can you format it how you would like to see it? Should it be a unified
diff? I agree it would help to see "what changed" but also don't know
what you want so opted to provide more information, not less. I was
worried about the questions like "do you change other parts of a splat?"
so I just put the whole thing there.

> 
> ...
> 
> > +#ifdef CONFIG_STACKTRACE_BUILD_ID
> > +     /* Module build ID */
> > +     unsigned char build_id[BUILD_ID_SIZE_MAX];
> 
> Is it really string of characters? Perhaps u8 will be more explicit.

I'm just matching the build ID API that uses unsigned char. If you want
u8 then we should update more places. I could do that in a followup
patch, but this one is already sorta big.

> 
> ...
> 
> > +#include <linux/kernel.h>
> 
> What do you need this header for?
> 

For typeof_member().