linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
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: Thu, 14 May 2020 10:00:53 +0200	[thread overview]
Message-ID: <20200514080053.GN17734@linux-b0ei> (raw)
In-Reply-To: <2173e3ac-7d5e-24da-0c1e-6472df905767@i-love.sakura.ne.jp>

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

  reply	other threads:[~2020-05-14  8:01 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
2020-05-14  8:00                                   ` Petr Mladek [this message]
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=20200514080053.GN17734@linux-b0ei \
    --to=pmladek@suse.com \
    --cc=dima@arista.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).