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: <2173e3ac-7d5e-24da-0c1e-6472df905767@i-love.sakura.ne.jp>
Date:   Wed, 13 May 2020 21:59:23 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Petr Mladek <pmladek@...e.com>
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 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,

> 
> [*] It will have no effect when it was disabled by a sysfs knob.

we will have to ask people to "don't make pr_debug() no-op" or
"use KERN_DEBUG instead of pr_debug()".

Your suggestion to change KERN_$LOGLEVEL keeps bothering people. That's bad.

> 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".

On 2020/05/13 21:34, Petr Mladek wrote:
> On Wed 2020-05-13 20:03:53, Tetsuo Handa wrote:
>> On 2020/05/13 19:04, Petr Mladek wrote:
>>>> 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
>>
>> KERN_NO_CONSOLES is different from KERN_DEBUG in that KERN_NO_CONSOLES
>> itself does not affect userspace daemon's judgement (whether to filter
>> KERN_$LOGLEVEL messages).
> 
> And that is the evil thing about it. It goes around the loglevel
> filtering.
> 
> The administrator wants to decide what messages are important for him.

Right.

> 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.

>                                                Users would need to
> investigate what the hell is happening. They would need to find the
> new sysfs knob to restore the expected behavior, etc.

That's part of deciding what messages are important for him, as well as
deciding what KERN_$LOGLEVEL messages are worth printing to consoles.