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

[Tetsuo Handa]

On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit printk
>> context information. But doesn't such attempt resemble find_printk_buffer() ?
> 
> Adding KERN_UNSUPPRESSED to all printks down the op_p->handler()
> line is hardly possible. At the same time I'd really prefer not
> to have buffering for sysrq.

I don't think it is hardly possible. And I really prefer having
deferred printing for SysRq.

SysRq is triggered by writing to /proc/sysrq-trigger or typing special keys
on the keyboard. This means that SysRq can be triggered by administrator's
will, and SysRq can be repeated/retried by administrator's will. Therefore,
allowing SysRq-t to write to consoles after leaving the atomic context is
an improvement. My proposal allows deferred printing for SysRq, dump_header()
and warn_alloc(). We can try to wake up console_writer kernel thread upon
leaving the atomic context. If the kernel is unhealthy enough to make
console_writer kernel thread defunctional, administrator can issue other
SysRq in order to forcibly write to consoles.

Is the attempt of making printk() completely asynchronous going to be resumed?
I think that "automatically asynchronous" won't be accepted, and I think that
at best "explicitly asynchronous" (by allowing the caller to explicitly say
it using printk() argument) is possible. (Maybe "asynchronous by default" and
"explicitly synchronous" is possible. But "explicitly synchronous" would be
told by using printk() argument rather than by implicit/global printk context
information...)

Anyway, forcing SysRq output to apply ignore_loglevel will be doable using
printk() argument.