Re: [PATCH] printk: Add loglevel for "do not print to consoles".

[Steven Rostedt]

On Fri, 24 Apr 2020 11:42:39 +0900
Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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