lkml.org 
[lkml]   [2019]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2019-05-28 06:16    [W:4.931 / U:0.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site