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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200514080053.GN17734@linux-b0ei>
Date:   Thu, 14 May 2020 10:00:53 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Michal Hocko <mhocko@...nel.org>,
        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 2020-05-13 21:59:23, Tetsuo Handa wrote:
> On 2020/05/13 21:19, Petr Mladek wrote:
> > On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
> >> On 2020/05/13 19:49, Michal Hocko wrote:
> >>> 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?
> >  
> >> I don't think dump_tasks() is important information to be printed on consoles.
> >> But since somebody might think dump_tasks() is important information to be
> >> printed on consoles, I suggest switching KERN_NO_CONSOLES using e.g. sysctl.
> > 
> > You might achieve the same with DEBUG loglevel. Or do I miss anything?
> 
> Use of KERN_DEBUG affects userspace syslog daemon. We will have to ask administrators
> to configure syslog daemon not to filter KERN_DEBUG messages. And administrators will
> be bothered by needless KERN_DEBUG messages. Also,

What about using KERN_INFO then? Is there still the same problem?

Otherwise this looks like a dead end. The above states that
administrators will not have to do anything when KERN_NO_CONSOLES
are introduced. But there are people that will not like the new
behavior. They will have to do something.


> > I know that it is meant as a modifier, like LOGLEVEL_SCHED and
> > KERN_CONT.
> 
> Right. KERN_NO_CONSOLES is a modifier.
> 
> >            But this is another reason to avoid it. We already have
> > huge pain with these two modifiers. They both do not work well.
> 
> KERN_NO_CONSOLES can not cause pains like LOGLEVEL_SCHED because
> KERN_NO_CONSOLES is to say "no need to call console drivers" while
> LOGLEVEL_SCHED is to say "don't call console drivers now but have
> to call console drivers later".

The problem with LOGLEVEL_SCHED is that it is not reliable. It must be
used for all printk() calls in the critical path. But people are not
aware of this, or they forget, or it gets complicated in shared code.

KERN_NO_CONSOLES will have exactly the same problems.

KERN_CONT is not reliable also from other reasons.


> > NO_CONSOLES would mess with this decision. Some messages would suddenly
> > get hidden on console but appear in userspace.
> 
> Wrong. Console loglevel is already hiding some messages.

Exactly and people are aware of it. We should use it when possible
instead of introducing yet another complexity.

Best Regards,
Petr