Message-ID: <YNnD3b1wKfDODKnw@alley>
Date:   Mon, 28 Jun 2021 14:43:09 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Dmitry Safonov <dima@...sta.com>
Cc:     linux-kernel@...r.kernel.org,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        John Ogness <john.ogness@...utronix.de>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] printk: Add CONFIG_CONSOLE_LOGLEVEL_PANIC

On Fri 2021-06-25 13:17:43, Dmitry Safonov wrote:
> Hi Petr, thanks for looking into this,
> 
> On 6/25/21 10:13 AM, Petr Mladek wrote:
> > On Tue 2021-06-22 15:33:50, Dmitry Safonov wrote:
> [..]
> >> @@ -76,8 +76,8 @@ static inline void console_silent(void)
> >>  
> >>  static inline void console_verbose(void)
> >>  {
> >> -	if (console_loglevel)
> >> -		console_loglevel = CONSOLE_LOGLEVEL_MOTORMOUTH;
> >> +	if (console_loglevel && (CONFIG_CONSOLE_LOGLEVEL_PANIC > 0))
> >> +		console_loglevel = CONFIG_CONSOLE_LOGLEVEL_PANIC;
> > 
> > console_verbose() is called also in some other situations.
> > For example, check_hung_task(), oops_begin(), debug_locks_ff().
> > These do not always lead to panic.>
> > At minimum, the name is misleading. It should be something
> > like CONFIG_CONSOLE_LOGLEVEL_VERBOSE.
> 
> Hmm, check_hung_task() calls it only if it's going to panic().

Yup.

> debug_locks_off() AFAICS is called only when there is something bad with
> either lockdep itself or locks: they may get freed
> [print_freed_lock_bug()] or lock is held on return to userspace
> [lockdep_sys_exit()] and so on - when lockdep has to turn off. Arguably,
> the situations are somewhat close to panic.

"Somewhat close to panic" is not enough. The important thing is to
see the messages in these critical situations. One way is the verbose
console. The other way is the crash dump. And the crashdump is
generated only when panic() is really called.

BTW: It might actually be better to handle this using a command line
option instead of build option. The build option prevents debugging
the problem when crash dump fails from some reason. It is always
much easier to remove a command line option than rebuild and install
anoter kernel.

> MCE calls it also just before panic.

yup.

> So, the only left is oops_begin().
> I'm not sure what to do about it.
> What do you think, should console_verbose() be called only under
> panic_on_oops?

No. IMHO, it is even more important to make the console_verbose()
when panic_on_oops is disabled. Oops means that there is a high
risk that the system might crash. And the worst thing is a silent
crash (no message, no crashdump).


> Or should there be console_unverbose() to return the
> loglevel in oops_end()? [that seems quite a bit ugly, considering that
> there're already places that temporary save loglevel and adding another
> one is ugh]

Yeah, the temporary console_loglevel changes are ugly. They might be
racy if two processes manipulate the loglevel in parallel.
We should keep them at minimum or better remove them at all.


> Renaming console_verbose() to console_verbose_on_panic() or something
> sounds good to me - I didn't do it only to keep the patch short.

Yup, it looks like to most reasonable approach to me.


> >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> >> index 678c13967580..0c12cafd9d8b 100644
> >> --- a/lib/Kconfig.debug
> >> +++ b/lib/Kconfig.debug
> >> @@ -61,6 +61,19 @@ config CONSOLE_LOGLEVEL_QUIET
> >>  	  will be used as the loglevel. IOW passing "quiet" will be the
> >>  	  equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>"
> >>  
> >> +config CONSOLE_LOGLEVEL_PANIC
> >> +	int "panic console loglevel (1-15)"
> > 
> > The range is 1-15 here.
> > 
> >> +	range 0 15
> > 
> > But it is 0-15 here. If you use "range 1 15" you should not need the
> > check (CONFIG_CONSOLE_LOGLEVEL_PANIC > 0) in the code.
> > 
> >> +	default "15"
> >> +	help
> >> +	  loglevel to use in kernel panic or oopses.
> >> +
> >> +	  Usually in order to provide more debug information on console upon
> >> +	  panic, one wants to see everything being printed (loglevel = 15).
> >> +	  With an exception to setups with low baudrate on serial console,
> >> +	  keeping this value high is a good choice.
> >> +	  0 value is to keep the loglevel during panic/oops unchanged.
> > 
> > The trick with 0 value just makes things more complicated. The default
> > "15" does the same job and should be good enough. The hard-coded
> > default is good enough for the other CONSOLE_LOGLEVEL_* settings.
> 
> Well, "0" is kinda reverse to "15" - it doesn't change loglevel at all.
> Actually, the origin purpose of the patch is to have "0" :-)

Is it enough to keep the current level during panic()? It might be
easier to introduce a commandline option, for example, no_console_verbose_panic.
It would do:

static inline void console_verbose_panic(void)
{
	if (!no_console_verbose_panic)
		console_verbose();
}

It is clear what it does. On the other hand, the logic with particular
loglevels is not clear. 3 different proposals has already been mentioned
in this thread:

	if (console_loglevel &&
	    (CONFIG_CONSOLE_LOGLEVEL_PANIC > console_loglevel)) {
		console_loglevel = CONFIG_CONSOLE_LOGLEVEL_PANIC;
	}

vs.

	if (console_loglevel)
		console_loglevel = CONFIG_CONSOLE_LOGLEVEL_PANIC;

vs.

	if (console_loglevel && CONFIG_CONSOLE_LOGLEVEL_PANIC)
		console_loglevel = CONFIG_CONSOLE_LOGLEVEL_PANIC;


Just imagine that you are a distributor, developer or admin:

   What value you would choose for CONFIG_CONSOLE_LOGLEVEL_PANIC?
   What console loglevel will be used at the end?

The answer depends on the implemented alhorith, console_loglevel,
and CONFIG_CONSOLE_LOGLEVEL_PANIC.

The answer would be much easier if "no_verbose_console_panic" is
used instead.

Best Regards,
Petr

Powered by blists - more mailing lists