[<prev] [next>] [day] [month] [year] [list]
Message-ID: <161661264804.3012082.14951998760354509511@swboyd.mtv.corp.google.com>
Date: Wed, 24 Mar 2021 12:04:08 -0700
From: Stephen Boyd <swboyd@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Baoquan He <bhe@...hat.com>, Borislav Petkov <bp@...en8.de>,
Catalin Marinas <catalin.marinas@....com>,
Dave Young <dyoung@...hat.com>,
Evan Green <evgreen@...omium.org>,
Hsin-Yi Wang <hsinyi@...omium.org>,
Ingo Molnar <mingo@...hat.com>, Jessica Yu <jeyu@...nel.org>,
Jiri Olsa <jolsa@...nel.org>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Matthew Wilcox <willy@...radead.org>,
Petr Mladek <pmladek@...e.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Sasha Levin <sashal@...nel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vivek Goyal <vgoyal@...hat.com>, Will Deacon <will@...nel.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v2 00/12] Add build ID to stacktraces
HTML mail?
Quoting Konstantin Khlebnikov (2021-03-24 01:23:55)
> 24.03.2021, 05:04, "Stephen Boyd" <swboyd@...omium.org>:
>
> Looks too noisy for me. Maybe print id in the line "Modules linked in:"?
> I suppose only out-of-tree modules need this?
>
Please see this note in patch 4:
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.
Powered by blists - more mailing lists