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

[Petr Mladek]

On Mon 2019-06-03 15:51:53, Sergey Senozhatsky wrote:
> 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,

Just to be sure. I wanted to say that I like the idea with
KERN_UNSUPRESSED. So, I think that we are on the same page.

> except for console_verbose(), which seems the be the only legit
> case.

Note that CONSOLE_LOGLEVEL_SILENT is used in vkdb_printf(). I do not
know the background. But it might make some sense in kdb context.

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

Yes, KERN_EMERG would do similar job.

Well, my understanding is that KERN_UNSUPRESSED would be used even
for less critical messages because the visibility is required
by the context or situation in which they are printed.

For example, we want to make all information visible in Oops because
the machine might be about to die. We might call there some shared
functions that produce less important messages in another context.

Also the pr_info() in __handle_sysrq() provides just informative
content. My understanding is that we want to show it just because
sysrq might be called when the system is not responding and we want
to give the user some feedback that the sysrq handler was called.

Now, KERN_EMERG might alarm some monitor of console output. It might
trigger unwanted reaction (forced reboot?) of the monitoring system
even when sysrq was not called in emergency situation.

I am sure that we need to care about such monitors. I have to
think more about it.

Best Regards,
Petr