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]

Message-ID: <20200513104938.GW29153@dhcp22.suse.cz>
Date:   Wed, 13 May 2020 12:49:38 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        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 13-05-20 12:04:13, Petr Mladek wrote:
> What is so special about  OOM dump task so that it would deserve such
> complications?

Nothing really. Except for the potential amount of the output. But as
you've said there are two ways around that. Disable this output if you
do not need it or make it a lower loglevel. A completely different
method of tagging messages just to distinguish different backends of the
printk ring buffers sounds like a bad idea to me because it a) adds a
policy to the kernel and b) it makes it incredibly hard to judge when to
use such a feature. I simply cannot tell whether somebody considers
dump_tasks an important information to be printed on consoles.

If there is any need to control which messages should be routed to which
backend then the proper solution would be to filter messages per log
level per backend. But I have no idea how feasible this is for the
existing infrastructure - or maybe it already exists...
-- 
Michal Hocko
SUSE Labs