Re: [RFC] printk/sysrq: Don't play with console_loglevel

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (05/28/19 15:42), Petr Mladek wrote:
> On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
> > On (05/28/19 13:15), Sergey Senozhatsky wrote:
> > > On (05/28/19 01:24), Dmitry Safonov wrote:
> > > [..]
> > > > While handling sysrq the console_loglevel is bumped to default to print
> > > > sysrq headers. It's done to print sysrq messages with WARNING level for
> > > > consumers of /proc/kmsg, though it sucks by the following reasons:
> > > > - changing console_loglevel may produce tons of messages (especially on
> > > >   bloated with debug/info prints systems)
> > > > - it doesn't guarantee that the message will be printed as printk may
> > > >   deffer the actual console output from buffer (see the comment near
> > > >   printk() in kernel/printk/printk.c)
> > > > 
> > > > Provide KERN_UNSUPPRESSED printk() annotation for such legacy places.
> > > > Make sysrq print the headers unsuppressed instead of changing
> > > > console_loglevel.
> 
> I like this idea. console_loglevel is temporary manipulated only
> when some messages should or should never appear on the console.
> Storing this information in the message flags would help
> to solve all the related races.

I don't really like the whole system-wide console_loglevel manipulation
thing, expect for console_verbose(), which seems the be the only legit
case. Maybe we better do something about it. I like the idea of
KERN_UNSUPPRESSED, especially if it will let us to completely remove
those console_loglevel manipulations.
E.g.

	console_loglevel = NEW;
	foo()
	 bar()
	  dump_stack();
	  ....
        console_loglevel = OLD;

    I understand the intent, but printk() is deferred (not always but still),
    so this code is not really expected to do the same thing all the time.
    Especially when it comes to NMI, etc.

If KERN_UNSUPPRESSED is going to be yet-another-way-to-print-important-messages
then I'm slightly less excited.

	-ss