[PATCH 00/50] Add log level to show_stack()
Petr Mladek
pmladek at suse.com
Wed Nov 6 19:35:38 AEDT 2019
On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
>
> Justification:
> o It's a design mistake to move a business-logic decision
> into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
> Removing console_loglevel jumps in sysrq driver [1]
Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.
IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.
> Hung task warning before panic [2] - suggested by Tetsuo (but he
> probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
> and other messages for each situation - so there won't be a situation
> when the backtrace is printed, but the headers are missing because
> they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.
> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.
I agree with all the other justification.
I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.
I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.
Best Regards,
Petr
More information about the Linuxppc-dev
mailing list