Re: [Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Josh Triplett <josh@joshtriplett.org>]

On Thu, Jul 21, 2016 at 09:46:16AM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (07/20/16 15:54), Josh Triplett wrote:
> [..]
> > > That's what I've tried to infer by the above statement; KERN_EMERG could
> > > easily used for that sort of thing.
> > 
> > I don't mean using just the priority level of the printk call.  I mean
> > using the current kernel loglevel, as in what level it displays to the
> > console, as set on the kernel command line with the loglevel= parameter.
> > printk could quickly check the priority level of the call versus the
> > current kernel loglevel to determine if the message would go to the
> > console or not, and use that to decide whether to handle it
> > synchronously or asynchronously.
> 
> between loglevel check in printk() and actual printing console loglevel
> may change. thus printk() does not make this (severity level filtering)
> decision. console_unlock() does, on per-log record basis:
[...]
> and by the time we call console_unlock() we better already be
> either in async mode, or sync mode. unless we want to rewrite
> console_unlock().

That's exactly why I was suggesting this filter.  Yes, loglevel can
change at any time, but I don't think it's worth worrying about whether
messages that happen to race with the change to loglevel get handled
synchronously or asynchronously.