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: <20200424092816.62a61b1d@gandalf.local.home>
Date:   Fri, 24 Apr 2020 09:28:16 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
        Michal Hocko <mhocko@...e.com>,
        Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".

On Fri, 24 Apr 2020 11:42:39 +0900
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> wrote:

> Since dump_tasks() is capable of generating thousands of printk() lines,
> it can significantly delay solving OOM situation by killing a process
> via the OOM killer. There is /proc/sys/vm/oom_dump_tasks which allows
> suppressing dump_tasks(), but those who diagnose the reason of OOM need
> dump_tasks() in order to understand memory usage as of invocation of the
> OOM killer. Therefore, setting /proc/sys/vm/oom_dump_tasks to 0 cannot be
> an option. Also, since userspace syslog daemon is likely configured not
> to save low (e.g. KERN_DEBUG) loglevels, reducing loglevel used by
> dump_tasks() cannot be an option. We want to maintain current loglevels
> in order to allow saving kernel messages to log files while we also want
> to avoid delays caused by printing to consoles due to maintaining current
> loglevels.
> 
> While an attempt to make printk() asynchronous (i.e. defer printing to
> consoles) and an attempt to make printk() to print to only selected
> consoles (i.e. don't print unimportant messages to slow consoles) are
> in progress, there are printk() callers where saving to log files is
> useful for later analysis but printing to consoles for immediate
> notification makes little sense. Two examples of such printk() callers
> will be the OOM killer and memory allocation failure messages. Therefore,
> this patch introduces a loglevel KERN_NO_CONSOLES which prevents all
> consoles from printing such messages.
> 
> Since both KERN_NO_CONSOLES messages and !KERN_NO_CONSOLES messages are
> stored into common printk buffer, KERN_NO_CONSOLES messages will be
> retrievable from the vmcore file even if something bad (e.g. NULL pointer
> dereference) followed. Therefore, as long as a system is configured for
> later analysis, ability to suppress printing to consoles will be useful.
> Since Dmitry Safonov is working on adding loglevel argument to
> show_stack(), we will in near future be able to control whether
> dump_stack() output is important enough to immediately print to consoles,
> by adding loglevel argument to dump_stack().
> 


Please no.

What I would suggest doing is create your own buffer to store the output.
Then use the seq_buf() operations and such to print to that buffer, and
then be able to read that output from something like a debug filesystem, or
some user space daemon that will write to syslog.

I do not want 'silent' writes to the printk buffer. It's bad enough that it
gets blown away by systemd.

-- Steve