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: <7af6fc77-986a-8a6a-ea93-b807db44413c@i-love.sakura.ne.jp>
Date:   Thu, 14 May 2020 20:23:55 +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/14 17:00, Petr Mladek wrote:
> 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?

dump_tasks() is already using KERN_INFO, and the same problem remains. KERN_INFO cannot
prevent printk() from printing to consoles unless console loglevel is tuned. And tuning
console loglevel can prevent all KERN_INFO from printing to consoles. What I want is a
method for allowing administrators to control whether to print each message to consoles.
Such method will be by definition controlled via "+ loglevel assigned to each message".

> 
> Otherwise this looks like a dead end.

Please please please DON'T IGNORE THE SWITCH.

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

Exactly. Therefore, we will need a switch which controls whether to add
KERN_NO_CONSOLES modifier (e.g. extending /proc/sys/vm/oom_dump_tasks if
KERN_NO_CONSOLES were useful to only dump_tasks()). Practically I would
propose /proc/sys/vm/print_oom_messages which is a bitmap for which OOM-
related messages should prevent printk() from being written to consoles.

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

I was worrying about difficulty in the callee side, but you are worrying
about difficulty of the caller side. Then, ...

> 
> KERN_NO_CONSOLES will have exactly the same problems.

No. That is a pointless concern.
Forgetting to add KERN_NO_CONSOLES is unrelated to the critical path.

> 
> KERN_CONT is not reliable also from other reasons.

Again, a pointless concern. We can try to eliminate KERN_CONT from printk()
callers when adding KERN_NO_CONSOLES to printk() callers, provided that
KERN_CONT could become a concern.

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

What I'm saying is:

  Don't count on KERN_$LOGLEVEL. Like you said "developers already have
  troubles to decide between the existing 8 loglevels.", there are only 8
  levels which are effectively unchangable/unusable for controlling which
  messages should be printed to consoles. Therefore, allow developers and
  administrators to control which messages should not be printed to consoles
  using SOME SWITCH YOU ARE IGNORING. Majority of kernel messages are not
  urgent enough to require synchronously writing to consoles. Only oops-
  related messages (and possibly watchdog-related messages) would worth
  writing to consoles synchronously. Skip writing non-urgent messages when
  urgent condition happens will be a concern when asynchronous printk() is
  added. If KERN_NO_CONSOLES were introduced, we can allow developers and
  administrators to control which messages are non-urgent messages.

Given that said, if KERN_NO_CONSOLES is not acceptable, I have to again
battle against Michal Hocko regarding how to offload OOM-related messages,
like Sergey Senozhatsky estimated

  "I'd say that lockless logbuf probably will land sometime around 5.8+.
  Async printk() - unknown."

last month.