All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Petr Mladek <pmladek@suse.com>
Cc: Michal Hocko <mhocko@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Dmitry Safonov <dima@arista.com>,
	Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".
Date: Wed, 13 May 2020 21:59:23 +0900	[thread overview]
Message-ID: <2173e3ac-7d5e-24da-0c1e-6472df905767@i-love.sakura.ne.jp> (raw)
In-Reply-To: <20200513121942.GK17734@linux-b0ei>

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.


  reply	other threads:[~2020-05-13 13:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24  2:42 [PATCH] printk: Add loglevel for "do not print to consoles" Tetsuo Handa
2020-04-24 13:28 ` Steven Rostedt
2020-04-24 14:00   ` Tetsuo Handa
2020-04-24 14:31     ` Steven Rostedt
2020-04-24 15:28       ` Tetsuo Handa
2020-04-24 15:42         ` Steven Rostedt
2020-04-24 15:52           ` Dmitry Safonov
2020-04-24 16:10           ` Tetsuo Handa
2020-04-24 16:21             ` Steven Rostedt
2020-04-24 16:34               ` Tetsuo Handa
2020-04-25  0:46 ` Sergey Senozhatsky
2020-04-25  1:07   ` Tetsuo Handa
2020-04-27  6:21     ` Sergey Senozhatsky
2020-04-28 11:33       ` Tetsuo Handa
2020-04-28 12:18         ` Michal Hocko
2020-04-28 13:11           ` Tetsuo Handa
2020-04-28 15:45             ` Michal Hocko
2020-04-28 16:23               ` Tetsuo Handa
2020-04-29 14:21                 ` Michal Hocko
2020-04-29 16:35                   ` Tetsuo Handa
2020-05-13  6:26                     ` Sergey Senozhatsky
2020-05-13  7:58                       ` Tetsuo Handa
2020-05-13 10:04                         ` Petr Mladek
2020-05-13 10:49                           ` Michal Hocko
2020-05-13 11:24                             ` Tetsuo Handa
2020-05-13 12:19                               ` Petr Mladek
2020-05-13 12:59                                 ` Tetsuo Handa [this message]
2020-05-14  8:00                                   ` Petr Mladek
2020-05-14 11:23                                     ` Tetsuo Handa
2020-05-14 16:26                                       ` Petr Mladek
2020-05-14 23:24                                         ` Tetsuo Handa
2020-05-13 11:03                           ` Tetsuo Handa
2020-05-13 12:34                             ` Petr Mladek
2020-05-13 13:46                             ` Steven Rostedt
2020-05-13 14:03                               ` Tetsuo Handa
2020-05-13 13:55                             ` Steven Rostedt
2020-05-13 15:20                               ` Tetsuo Handa
2020-05-06  9:45         ` Tetsuo Handa
2020-05-06 15:26           ` Joe Perches
2020-05-07  0:50             ` Tetsuo Handa
2020-05-07  1:02               ` Joe Perches
2020-05-07  5:13                 ` Tetsuo Handa
2020-05-07  5:30                   ` Joe Perches
2020-05-07  5:39                     ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2173e3ac-7d5e-24da-0c1e-6472df905767@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=dima@arista.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.