linux-kernel - Re: [PATCH] printk: Add loglevel for "do not print to consoles".

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 May 2020 12:04:13 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Michal Hocko <mhocko@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
        Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".

On Wed 2020-05-13 16:58:48, Tetsuo Handa wrote:
> On 2020/05/13 15:26, Sergey Senozhatsky wrote:
> > Yes, but this looks like it's the consumer of the messages who
> > decides what to filter and what not to. rsyslog, dmesg, etc.
> > will have different filtering policies. It's not like the kernel
> > decides what to hide and what to show. If would compare this to
> > NO_CONSOLES, then NO_CONSOLES does a different thing after all.
> 
> I just showed an example that changing dump_tasks() messages from
> KERN_INFO to KERN_DEBUG is not an option. If dump_tasks() were using
> KERN_DEBUG, the consumer of the messages will have to receive all
> KERN_DEBUG messages, which needlessly contains uninterested messages.
> If dump_tasks() allows use of NO_CONSOLES (via e.g. sysctl switch),
> the consumer does not need to receive KERN_DEBUG messages.
> 
> What is wrong with adding NO_CONSOLES ?

How does it differ from KERN_DEBUG? The debug messages:

  + can be disabled via sysfs
  + might reach console when this loglevel is enabled


The console loglevel handling is already very complicated. The
behavior is affected by:

  + four values in console_printk array:
      + console_loglevel
      + default_message_loglevel
      + minimum_console_loglevel
      + default_console_loglevel

  + ignore_loglevel variable

  + loglevel assigned to each message


I really do not see a reason for another loglevel, another sysfs
interface, and another special handling. It would just make it even
more complicated for both developers and users.

What is so special about  OOM dump task so that it would deserve such
complications?

The dump might already be enabled or disabled. If is not important
enough to reach the console then the messages should be printed
with a lower loglevel.

Best Regards,
Petr