Messages in this thread | | | Date | Tue, 28 May 2019 13:15:00 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC] printk/sysrq: Don't play with console_loglevel |
| |
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. Hence we can use per-CPU flag to tell printk that whatever comes from this-CPU is important and printk should eventually print it (next time it hits console_unlock()). One candidate for such per-CPU flag was this_cpu(printk_context). We can steal high bit (next to NMI printk_safe bit). So the intended use case was something like this
sysrq/etc /* atomic context */ { printk_blah_enter();
for (...) printk(); ... dump_bar();
prinkt_blah_exit(); }
printk_blah_enter() would set that special - printk_safe_mask_blah - bit, and prinkt_blah_exit() would clear it. Whenever prinkt->vprintk_store() would see printk_safe_mask_blah bit set it would mark the log_stored message as "important, always print!", and console_unlock() would always print those "important" messages.
-ss
| |