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've been thinking about this a while ago... So what I thought back
> then was that affected paths are atomic: sysrq, irqs, NMI, etc. Well
> at leasted it seemed to be so.
Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
printk-safe redirections.
NMI
loglevel = NEW
printk -> printk_safe_nmi
loglevel = OLD
iret
IRQ
flush printk_safe_nmi -> printk
// At this point we don't remember about
// loglevel manipulation anymore
iret
We, probably, still need some flags to pass the "this was supposed to
be an important messages" info from printk-safe to normal printk. On
the other hand, if NMI printk-s then it's something rather important,
so we probably better print it anyway and avoid suppress_message_printing()
check for messages which are coming from printk-NMI buffers. To some
extent, it's the same with printk-safe: we don't use it unless we have
a very good reason. So if there is something in printk-safe buffers
then it better end up on consoles. So, maybe, we still can use that
per-CPU printk_context thing.
[1] https://lore.kernel.org/lkml/20180601044050.GA5687@jagdpanzerIV/
-ss
