Re: [PATCH v2] printk: make sure to print log on console.

[Petr Mladek <pmladek@suse.com>]

On Tue 2018-06-19 18:49:53, Sergey Senozhatsky wrote:
> On (06/19/18 11:32), Petr Mladek wrote:
> > > -               if (suppress_message_printing(msg->level)) {
> > > +               if (!ignore_loglevel && (msg->flags & LOG_NOCONS)) {
> > > 
> > > 
> > > `ignore_loglevel' is a module param and can change any time via
> > > 	/sys/module/printk/parameters/ignore_loglevel
> > > we need to respect its value.
> > 
> > I would prefer to keep the patch as is. I see it the following way.
> > 
> > Also console_loglevel can be changed anytime by /proc/sys/kernel/printk.
> > The patch basically moves the decision about the message visibility from
> > console_unlock() to vprintk_emit(). The logic is easier when all
> > aspects are handled in a single location and only once.
> 
> But when I set /sys/module/printk/parameters/ignore_loglevel I naturally
> expect it to take an immediate action. Without waiting for the consoles
> to catch up and to discard N messages [if the consoles were behind the
> logbuf head].

Yeah, I understand this view. I thought about it as well. But did you
ever needed this behavior in the real life?

I personally changed ignore_loglevel only before I wanted to reproduce a
bug. Then it would be perfectly fine to handle it only in
vprintk_emit(). In fact, it would be even better because it would
affect only messages that happened after I triggered the bug.

Anyway, changing ignore_loglevel during a printk flood has undefined
behavior by definition. If you do this manually, it would depend on
the speed of the console, your typing capabilities, possibility to
login as administrator, load of the system, ... If you do this
by a script, you would probably do it in advance. I do not see
this a reason for a more complicated and even schizophrenic logic.

Best Regards,
Petr