linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] printk: Add loglevel for "do not print to consoles".
@ 2020-04-24  2:42 Tetsuo Handa
  2020-04-24 13:28 ` Steven Rostedt
  2020-04-25  0:46 ` Sergey Senozhatsky
  0 siblings, 2 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-24  2:42 UTC (permalink / raw)
  To: Petr Mladek, Sergey Senozhatsky, Steven Rostedt
  Cc: linux-kernel, Tetsuo Handa, Dmitry Safonov, Michal Hocko, Yafang Shao

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

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Dmitry Safonov <dima@arista.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Yafang Shao <laoar.shao@gmail.com>
---
 include/linux/kern_levels.h | 3 +++
 include/linux/printk.h      | 1 +
 kernel/printk/printk.c      | 7 ++++++-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/linux/kern_levels.h b/include/linux/kern_levels.h
index bf2389c26ae3..cd69a9cb3c2a 100644
--- a/include/linux/kern_levels.h
+++ b/include/linux/kern_levels.h
@@ -23,6 +23,9 @@
  */
 #define KERN_CONT	KERN_SOH "c"
 
+/* Annotation for "don't print to consoles". */
+#define KERN_NO_CONSOLES KERN_SOH "S"
+
 /* integer equivalents of KERN_<LEVEL> */
 #define LOGLEVEL_SCHED		-2	/* Deferred messages from sched code
 					 * are set to this special level */
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e061635e0409..da338b81c2e1 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -19,6 +19,7 @@ static inline int printk_get_level(const char *buffer)
 		switch (buffer[1]) {
 		case '0' ... '7':
 		case 'c':	/* KERN_CONT */
+		case 'S':       /* KERN_NO_CONSOLES */
 			return buffer[1];
 		}
 	}
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 9a9b6156270b..ed51641af087 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -361,6 +361,7 @@ static int console_msg_format = MSG_FORMAT_DEFAULT;
  */
 
 enum log_flags {
+	LOG_NO_CONSOLES = 1,    /* don't print to consoles */
 	LOG_NEWLINE	= 2,	/* text ended with a newline */
 	LOG_CONT	= 8,	/* text is a fragment of a continuation line */
 };
@@ -1959,6 +1960,9 @@ int vprintk_store(int facility, int level,
 				break;
 			case 'c':	/* KERN_CONT */
 				lflags |= LOG_CONT;
+				break;
+			case 'S':       /* KERN_NO_CONSOLES */
+				lflags |= LOG_NO_CONSOLES;
 			}
 
 			text_len -= 2;
@@ -2453,7 +2457,8 @@ void console_unlock(void)
 			break;
 
 		msg = log_from_idx(console_idx);
-		if (suppress_message_printing(msg->level)) {
+		if ((msg->flags & LOG_NO_CONSOLES) ||
+		    suppress_message_printing(msg->level)) {
 			/*
 			 * Skip record we have buffered and already printed
 			 * directly to the console when we received it, and
-- 
2.18.2


^ permalink raw reply related	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  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-25  0:46 ` Sergey Senozhatsky
  1 sibling, 1 reply; 44+ messages in thread
From: Steven Rostedt @ 2020-04-24 13:28 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-24 13:28 ` Steven Rostedt
@ 2020-04-24 14:00   ` Tetsuo Handa
  2020-04-24 14:31     ` Steven Rostedt
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-24 14:00 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On 2020/04/24 22:28, Steven Rostedt wrote:
> 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.

Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
sleep has failed), we can't create buffer on demand. For process context, it
would be possible to create buffer upon fork() time. But for atomic context,
it is so difficult to create buffer on demand. We could allocate shared buffer
like logbuf but it means that we have to replicate what printk() is doing (too
much code), for when atomic memory allocation happens resembles when printk()
is called. Borrowing printk()'s logbuf is simpler.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-24 14:00   ` Tetsuo Handa
@ 2020-04-24 14:31     ` Steven Rostedt
  2020-04-24 15:28       ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Steven Rostedt @ 2020-04-24 14:31 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On Fri, 24 Apr 2020 23:00:01 +0900
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
> can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
> sleep has failed), we can't create buffer on demand. For process context, it
> would be possible to create buffer upon fork() time. But for atomic context,
> it is so difficult to create buffer on demand. We could allocate shared buffer
> like logbuf but it means that we have to replicate what printk() is doing (too
> much code), for when atomic memory allocation happens resembles when printk()
> is called. Borrowing printk()'s logbuf is simpler.

I would have a buffer allocated for this at start up.

What exactly would you be "replicating" in printk? The point of printk is
to print to a console, not to be a generic ring buffer. This change is
breaking printk's most useful feature.

-- Steve

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-24 14:31     ` Steven Rostedt
@ 2020-04-24 15:28       ` Tetsuo Handa
  2020-04-24 15:42         ` Steven Rostedt
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-24 15:28 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On 2020/04/24 23:31, Steven Rostedt wrote:
> On Fri, 24 Apr 2020 23:00:01 +0900
> Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> 
>> Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
>> can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
>> sleep has failed), we can't create buffer on demand. For process context, it
>> would be possible to create buffer upon fork() time. But for atomic context,
>> it is so difficult to create buffer on demand. We could allocate shared buffer
>> like logbuf but it means that we have to replicate what printk() is doing (too
>> much code), for when atomic memory allocation happens resembles when printk()
>> is called. Borrowing printk()'s logbuf is simpler.
> 
> I would have a buffer allocated for this at start up.

Allocating global buffer itself is simple (except that it might waste a lot of
memory). Difficult part is how to use the buffer.

> 
> What exactly would you be "replicating" in printk?

Making it possible to store into global buffer from almost any context (not only
process context but also softirq/hardirq/NMI context (well, is memory allocation
 from NMI context not permitted? I don't know... but future KERN_NO_CONSOLES
users might want to call from NMI context)), notify userspace program of data
readiness, and manage the buffer.

KERN_NO_CONSOLES does not need to call call_console_drivers(). But basically
things what printk() is doing.

>                                                    The point of printk is
> to print to a console, not to be a generic ring buffer. This change is
> breaking printk's most useful feature.

For those who analyze log files (instead of console output), the point of
printk() is to save kernel messages into log files (via userspace syslog
daemon).

By the way, I think

  printk(KERN_NO_CONSOLES "hello\n")

is almost same with doing

  saved_loglevel = console_loglevel;
  console_loglevel = CONSOLE_LOGLEVEL_SILENT;
  printk("hello\n");
  console_loglevel = saved_loglevel;

used by vkdb_printf().


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  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
  0 siblings, 2 replies; 44+ messages in thread
From: Steven Rostedt @ 2020-04-24 15:42 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On Sat, 25 Apr 2020 00:28:53 +0900
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> On 2020/04/24 23:31, Steven Rostedt wrote:
> > On Fri, 24 Apr 2020 23:00:01 +0900
> > Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >   
> >> Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
> >> can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
> >> sleep has failed), we can't create buffer on demand. For process context, it
> >> would be possible to create buffer upon fork() time. But for atomic context,
> >> it is so difficult to create buffer on demand. We could allocate shared buffer
> >> like logbuf but it means that we have to replicate what printk() is doing (too
> >> much code), for when atomic memory allocation happens resembles when printk()
> >> is called. Borrowing printk()'s logbuf is simpler.  
> > 
> > I would have a buffer allocated for this at start up.  
> 
> Allocating global buffer itself is simple (except that it might waste a lot of
> memory). Difficult part is how to use the buffer.

I agree with Michal that this really should be a user setting (something on
the command line or sysctl - allocation at the time of decision).

> 
> > 
> > What exactly would you be "replicating" in printk?  
> 
> Making it possible to store into global buffer from almost any context (not only
> process context but also softirq/hardirq/NMI context (well, is memory allocation
>  from NMI context not permitted? I don't know... but future KERN_NO_CONSOLES
> users might want to call from NMI context)), notify userspace program of data
> readiness, and manage the buffer.

printk() was not safe in NMI context up until very recently.

You can also use the tracing ring buffer for this, as it has been safe in
all these contexts for a very long time. And that ring buffer is something
that you can use outside of tracing (oprofile uses it).


> 
> KERN_NO_CONSOLES does not need to call call_console_drivers(). But basically
> things what printk() is doing.
> 
> >                                                    The point of printk is
> > to print to a console, not to be a generic ring buffer. This change is
> > breaking printk's most useful feature.  
> 
> For those who analyze log files (instead of console output), the point of
> printk() is to save kernel messages into log files (via userspace syslog
> daemon).
> 
> By the way, I think
> 
>   printk(KERN_NO_CONSOLES "hello\n")
> 
> is almost same with doing
> 
>   saved_loglevel = console_loglevel;
>   console_loglevel = CONSOLE_LOGLEVEL_SILENT;
>   printk("hello\n");
>   console_loglevel = saved_loglevel;
> 
> used by vkdb_printf().

And both shouldn't be done within the kernel. The "CONSOLE_LOGLEVEL_SILENT"
if for user decided policy, not the kernel making that policy for the user.

-- Steve

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-24 15:42         ` Steven Rostedt
@ 2020-04-24 15:52           ` Dmitry Safonov
  2020-04-24 16:10           ` Tetsuo Handa
  1 sibling, 0 replies; 44+ messages in thread
From: Dmitry Safonov @ 2020-04-24 15:52 UTC (permalink / raw)
  To: Steven Rostedt, Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Michal Hocko, Yafang Shao



On 4/24/20 4:42 PM, Steven Rostedt wrote:
> On Sat, 25 Apr 2020 00:28:53 +0900
> Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> For those who analyze log files (instead of console output), the point of
>> printk() is to save kernel messages into log files (via userspace syslog
>> daemon).
>>
>> By the way, I think
>>
>>   printk(KERN_NO_CONSOLES "hello\n")
>>
>> is almost same with doing
>>
>>   saved_loglevel = console_loglevel;
>>   console_loglevel = CONSOLE_LOGLEVEL_SILENT;
>>   printk("hello\n");
>>   console_loglevel = saved_loglevel;
>>
>> used by vkdb_printf().
> 
> And both shouldn't be done within the kernel. The "CONSOLE_LOGLEVEL_SILENT"
> if for user decided policy, not the kernel making that policy for the user.

Though, I believe the reverse KERN_UNSUPPRESSED [1] still makes sense
for sysrq/kdb where user expects their interactive messages to appear on
console. And unfortunately, userspace depends on the loglevel of those
messages as it is.
With KERN_UNSUPPRESSED I hope to remove all those console_loglevel
tricks and make it static variable for printk.

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  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
  1 sibling, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-24 16:10 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On 2020/04/25 0:42, Steven Rostedt wrote:
> You can also use the tracing ring buffer for this, as it has been safe in
> all these contexts for a very long time. And that ring buffer is something
> that you can use outside of tracing (oprofile uses it).

Some messages are read from printk() source and other messages are read from
non-printk() source will loose ordering of messages (i.e. non-understandable
log files). For those who analyze log files, multiple sources are not acceptable.

> And both shouldn't be done within the kernel. The "CONSOLE_LOGLEVEL_SILENT"
> if for user decided policy, not the kernel making that policy for the user.

KERN_NO_CONSOLES is a mechanism for implementing user decided policy. As long as
userspace can control whether to use KERN_NO_CONSOLES (e.g. sysctl), there should
be no problem with adding KERN_NO_CONSOLES (i.e. this patch) to the kernel side.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-24 16:10           ` Tetsuo Handa
@ 2020-04-24 16:21             ` Steven Rostedt
  2020-04-24 16:34               ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Steven Rostedt @ 2020-04-24 16:21 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On Sat, 25 Apr 2020 01:10:15 +0900
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> KERN_NO_CONSOLES is a mechanism for implementing user decided policy. As long as
> userspace can control whether to use KERN_NO_CONSOLES (e.g. sysctl), there should
> be no problem with adding KERN_NO_CONSOLES (i.e. this patch) to the kernel side.

How would you define what gets "KERN_NO_CONSOLES"? Is it going to be a
sysctl switch?

Also, how does one control the log level of prints with KERN_NO_CONSOLES?

-- Steve

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-24 16:21             ` Steven Rostedt
@ 2020-04-24 16:34               ` Tetsuo Handa
  0 siblings, 0 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-24 16:34 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Sergey Senozhatsky, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On 2020/04/25 1:21, Steven Rostedt wrote:
> On Sat, 25 Apr 2020 01:10:15 +0900
> Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> 
>> KERN_NO_CONSOLES is a mechanism for implementing user decided policy. As long as
>> userspace can control whether to use KERN_NO_CONSOLES (e.g. sysctl), there should
>> be no problem with adding KERN_NO_CONSOLES (i.e. this patch) to the kernel side.
> 
> How would you define what gets "KERN_NO_CONSOLES"? Is it going to be a
> sysctl switch?

Yes. See
https://lkml.kernel.org/r/c95dfafb-fe9c-19d7-8d42-bcd7d0946867@i-love.sakura.ne.jp .

> 
> Also, how does one control the log level of prints with KERN_NO_CONSOLES?

I couldn't understand the question.

KERN_NO_CONSOLES is just a flag for not to call call_console_drivers().
Messages printed with printk(KERN_$LOGLEVEL KERN_NO_CONSOLES ...) will be
read by userspace syslog daemon and be filtered based on KERN_$LOGLEVEL.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  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-25  0:46 ` Sergey Senozhatsky
  2020-04-25  1:07   ` Tetsuo Handa
  1 sibling, 1 reply; 44+ messages in thread
From: Sergey Senozhatsky @ 2020-04-25  0:46 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Michal Hocko, Yafang Shao

On (20/04/24 11:42), Tetsuo Handa wrote:
[..]
> @@ -19,6 +19,7 @@ static inline int printk_get_level(const char *buffer)
>  		switch (buffer[1]) {
>  		case '0' ... '7':
>  		case 'c':	/* KERN_CONT */
> +		case 'S':       /* KERN_NO_CONSOLES */
>  			return buffer[1];
>  		}
>  	}

So this means NO_CONSOLES_AT_ALL, slow + fast ones. I wonder if this
wants to be NO_SLOW_CONSOLES instead. Which then brings us to the
next question - can this be done with per-console loglevel setting?

	-ss

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-25  0:46 ` Sergey Senozhatsky
@ 2020-04-25  1:07   ` Tetsuo Handa
  2020-04-27  6:21     ` Sergey Senozhatsky
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-25  1:07 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Petr Mladek, Steven Rostedt, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On 2020/04/25 9:46, Sergey Senozhatsky wrote:
> On (20/04/24 11:42), Tetsuo Handa wrote:
> [..]
>> @@ -19,6 +19,7 @@ static inline int printk_get_level(const char *buffer)
>>  		switch (buffer[1]) {
>>  		case '0' ... '7':
>>  		case 'c':	/* KERN_CONT */
>> +		case 'S':       /* KERN_NO_CONSOLES */
>>  			return buffer[1];
>>  		}
>>  	}
> 
> So this means NO_CONSOLES_AT_ALL, slow + fast ones.

Right.

>                                                     I wonder if this
> wants to be NO_SLOW_CONSOLES instead. Which then brings us to the
> next question - can this be done with per-console loglevel setting?

It is difficult to define what is slow consoles. While netconsole will be
a fast console, we can forward kernel messages via syslog daemon if desired.

NO_SLOW_CONSOLES might be useful for immediate notification like panic().
But KERN_NO_CONSOLES is not for immediate notification like panic().

KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
important but "printed for immediate notification" is not important.
In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
immediate notification" is important.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-25  1:07   ` Tetsuo Handa
@ 2020-04-27  6:21     ` Sergey Senozhatsky
  2020-04-28 11:33       ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Sergey Senozhatsky @ 2020-04-27  6:21 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Michal Hocko, Yafang Shao

On (20/04/25 10:07), Tetsuo Handa wrote:
> On 2020/04/25 9:46, Sergey Senozhatsky wrote:
> > On (20/04/24 11:42), Tetsuo Handa wrote:
> > [..]
> >> @@ -19,6 +19,7 @@ static inline int printk_get_level(const char *buffer)
> >>  		switch (buffer[1]) {
> >>  		case '0' ... '7':
> >>  		case 'c':	/* KERN_CONT */
> >> +		case 'S':       /* KERN_NO_CONSOLES */
> >>  			return buffer[1];
> >>  		}
> >>  	}
> > 
> > So this means NO_CONSOLES_AT_ALL, slow + fast ones.
> 
> Right.
> 
> >                                                     I wonder if this
> > wants to be NO_SLOW_CONSOLES instead. Which then brings us to the
> > next question - can this be done with per-console loglevel setting?
> 
> It is difficult to define what is slow consoles. While netconsole will be
> a fast console, we can forward kernel messages via syslog daemon if desired.

Yes, there is no universal definition for "fast" and "slow" console and
I'm not suggesting to come with such a definition.

> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
> important but "printed for immediate notification" is not important.
> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
> immediate notification" is important.

per-console loglevel is a user configurable parameter.
KERN_NO_CONSOLES is a hard-coded policy.

	-ss

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-27  6:21     ` Sergey Senozhatsky
@ 2020-04-28 11:33       ` Tetsuo Handa
  2020-04-28 12:18         ` Michal Hocko
  2020-05-06  9:45         ` Tetsuo Handa
  0 siblings, 2 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-28 11:33 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Petr Mladek, Steven Rostedt, linux-kernel, Dmitry Safonov,
	Michal Hocko, Yafang Shao

On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>> important but "printed for immediate notification" is not important.
>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
>> immediate notification" is important.
> 
> per-console loglevel is a user configurable parameter.
> KERN_NO_CONSOLES is a hard-coded policy.

But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-28 11:33       ` Tetsuo Handa
@ 2020-04-28 12:18         ` Michal Hocko
  2020-04-28 13:11           ` Tetsuo Handa
  2020-05-06  9:45         ` Tetsuo Handa
  1 sibling, 1 reply; 44+ messages in thread
From: Michal Hocko @ 2020-04-28 12:18 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> >> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
> >> important but "printed for immediate notification" is not important.
> >> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
> >> immediate notification" is important.
> > 
> > per-console loglevel is a user configurable parameter.
> > KERN_NO_CONSOLES is a hard-coded policy.
> 
> But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
> KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?

How do I as a kernel developer know that KERN_NO_CONSOLES should be
used? In other words, how can I assume what a user will consider
important on the console?

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-28 12:18         ` Michal Hocko
@ 2020-04-28 13:11           ` Tetsuo Handa
  2020-04-28 15:45             ` Michal Hocko
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-28 13:11 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/04/28 21:18, Michal Hocko wrote:
> On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
>> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>>>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>>>> important but "printed for immediate notification" is not important.
>>>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
>>>> immediate notification" is important.
>>>
>>> per-console loglevel is a user configurable parameter.
>>> KERN_NO_CONSOLES is a hard-coded policy.
>>
>> But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
>> KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
> 
> How do I as a kernel developer know that KERN_NO_CONSOLES should be
> used? In other words, how can I assume what a user will consider
> important on the console?
> 

Existing KERN_$LEVEL allows a user to determine whether he/she wants that message
to be printed on consoles (even if it spams his/her operation doing on consoles), and
at the same time constrains that user whether that message is saved to log files.
KERN_NO_CONSOLES allows a user to control whether he/she wants that message to be
saved to log files (without spamming his/her operation doing on consoles).

Consoles which are limited by "rows" * "columns" size should receive (ideally) up to
a few lines of messages. Printing more lines on such consoles disturbs users using
such consoles. Let alone printing one thousand lines of messages (e.g. dump_tasks())
on such consoles. Printing one thousand lines of messages on read-only consoles (e.g.
netconsole) might be fine, but non-urgent messages can afford waiting for userspace
to do more sophisticated handling (e.g. evaluate and filter).

Even without per-console loglevel feature, we can reduce spam messages for consoles
by using KERN_NO_CONSOLES. For example, send only the summary part of OOM-killer and
allocation failure messages to both consoles and log files (by not using KERN_NO_CONSOLES),
and send the non-summary part to only log files (by using KERN_NO_CONSOLES with 
KERN_$LEVEL used for summary part in order to make sure that userspace daemon will
save both the summary and non-summary parts).

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-28 13:11           ` Tetsuo Handa
@ 2020-04-28 15:45             ` Michal Hocko
  2020-04-28 16:23               ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Michal Hocko @ 2020-04-28 15:45 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
> On 2020/04/28 21:18, Michal Hocko wrote:
> > On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
> >> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> >>>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
> >>>> important but "printed for immediate notification" is not important.
> >>>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
> >>>> immediate notification" is important.
> >>>
> >>> per-console loglevel is a user configurable parameter.
> >>> KERN_NO_CONSOLES is a hard-coded policy.
> >>
> >> But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
> >> KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
> > 
> > How do I as a kernel developer know that KERN_NO_CONSOLES should be
> > used? In other words, how can I assume what a user will consider
> > important on the console?
> > 
> 
> Existing KERN_$LEVEL allows a user to determine whether he/she wants that message
> to be printed on consoles (even if it spams his/her operation doing on consoles), and
> at the same time constrains that user whether that message is saved to log files.
> KERN_NO_CONSOLES allows a user to control whether he/she wants that message to be
> saved to log files (without spamming his/her operation doing on consoles).

I understand that. But how do I know whether the user considers the
particular information important enough to be dumped on the console.
This sounds like a policy in the kernel to me. I simply cannot forsee
any console configuration to tell whether my information is going to
swamp the console to no use or not. Compare that to KERN_$LEVEL instead.
I know that an information is of low/high importance. It is the user
policy to decide and base some filtering on top of that priority.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-28 15:45             ` Michal Hocko
@ 2020-04-28 16:23               ` Tetsuo Handa
  2020-04-29 14:21                 ` Michal Hocko
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-28 16:23 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/04/29 0:45, Michal Hocko wrote:
> On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
>> Existing KERN_$LEVEL allows a user to determine whether he/she wants that message
>> to be printed on consoles (even if it spams his/her operation doing on consoles), and
>> at the same time constrains that user whether that message is saved to log files.
>> KERN_NO_CONSOLES allows a user to control whether he/she wants that message to be
>> saved to log files (without spamming his/her operation doing on consoles).
> 
> I understand that. But how do I know whether the user considers the
> particular information important enough to be dumped on the console.
> This sounds like a policy in the kernel to me.

I'm still unable to understand your question.

>                                                I simply cannot forsee
> any console configuration to tell whether my information is going to
> swamp the console to no use or not.

Neither can I.

>                                     Compare that to KERN_$LEVEL instead.
> I know that an information is of low/high importance. It is the user
> policy to decide and base some filtering on top of that priority.

Whether to use KERN_NO_CONSOLES is not per-importance basis but per-content basis.

Since both pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu         %5hd %s\n", ...) from dump_tasks() and
pr_info("oom-kill:constraint=%s,nodemask=%*pbl", ...) from dump_oom_summary() use KERN_INFO importance,
existing KERN_$LEVEL-based approach cannot handle these messages differently. Since changing the former to
e.g. KERN_DEBUG will cause userspace to discard the messages, we effectively can't change KERN_$LEVEL.
If the kernel allows the former to use KERN_NO_CONSOLES in addition to KERN_INFO, the administrator can
select from two choices: printing "both the former and the latter" or "only the latter" to consoles.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-28 16:23               ` Tetsuo Handa
@ 2020-04-29 14:21                 ` Michal Hocko
  2020-04-29 16:35                   ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Michal Hocko @ 2020-04-29 14:21 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Wed 29-04-20 01:23:15, Tetsuo Handa wrote:
> On 2020/04/29 0:45, Michal Hocko wrote:
> > On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
> >> Existing KERN_$LEVEL allows a user to determine whether he/she wants that message
> >> to be printed on consoles (even if it spams his/her operation doing on consoles), and
> >> at the same time constrains that user whether that message is saved to log files.
> >> KERN_NO_CONSOLES allows a user to control whether he/she wants that message to be
> >> saved to log files (without spamming his/her operation doing on consoles).
> > 
> > I understand that. But how do I know whether the user considers the
> > particular information important enough to be dumped on the console.
> > This sounds like a policy in the kernel to me.
> 
> I'm still unable to understand your question.

I am trying to say that KERN_NO_CONSOLES resembles more a policy than a
priority. Because I as a developer have no idea whether the message is
good enough for console or not.

> >                                                I simply cannot forsee
> > any console configuration to tell whether my information is going to
> > swamp the console to no use or not.
> 
> Neither can I.
> 
> >                                     Compare that to KERN_$LEVEL instead.
> > I know that an information is of low/high importance. It is the user
> > policy to decide and base some filtering on top of that priority.
> 
> Whether to use KERN_NO_CONSOLES is not per-importance basis but per-content basis.
> 
> Since both pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu         %5hd %s\n", ...) from dump_tasks() and
> pr_info("oom-kill:constraint=%s,nodemask=%*pbl", ...) from dump_oom_summary() use KERN_INFO importance,
> existing KERN_$LEVEL-based approach cannot handle these messages differently. Since changing the former to
> e.g. KERN_DEBUG will cause userspace to discard the messages, we effectively can't change KERN_$LEVEL.

I believe we are free to change kernel log levels as we find a fit. I
was not aware that KERN_DEBUG messages are automatically filtered out.
Even if this is the case then this doesn't really disallow admins to
allow KERN_DEBUG into log files. Dump of the oom eligible tasks is
arguably a debugging output anyway. So I disagree with your statement.

> If the kernel allows the former to use KERN_NO_CONSOLES in addition to KERN_INFO, the administrator can
> select from two choices: printing "both the former and the latter" or "only the latter" to consoles.

I am not really familiar with all the possibilities admins have when
setting filtering for different consoles but KERN_NO_CONSOLES sounds
rather alien to the existing priority based approach. You can fine tune
priorities and that is all right because they should be reflecting
importance. But global no-consoles doesn't really fit in here because
each console might require a different policy but the marking is
unconditional and largely unaware of existing consoles.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-29 14:21                 ` Michal Hocko
@ 2020-04-29 16:35                   ` Tetsuo Handa
  2020-05-13  6:26                     ` Sergey Senozhatsky
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-04-29 16:35 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/04/29 23:21, Michal Hocko wrote:
> I am trying to say that KERN_NO_CONSOLES resembles more a policy than a
> priority. Because I as a developer have no idea whether the message is
> good enough for console or not.

Right, KERN_NO_CONSOLES is not a priority.

> I believe we are free to change kernel log levels as we find a fit. I
> was not aware that KERN_DEBUG messages are automatically filtered out.

Below is the default rules for rsyslog-8.24.0-52.el7 (userspace syslog daemon).
Of course administrators can modify as needed, but notice that KERN_INFO is saved
to /var/log/messages but KERN_DEBUG is saved to nowhere.

----------
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
----------

> Even if this is the case then this doesn't really disallow admins to
> allow KERN_DEBUG into log files. Dump of the oom eligible tasks is
> arguably a debugging output anyway. So I disagree with your statement.

If dump_tasks() were changed to use KERN_DEBUG, administrators have to add
"kern.debug" rule (at the same time endure a lot of noise from KERN_DEBUG)
in order to record OOM victim candidates for later analysis.

> 
>> If the kernel allows the former to use KERN_NO_CONSOLES in addition to KERN_INFO, the administrator can
>> select from two choices: printing "both the former and the latter" or "only the latter" to consoles.
> 
> I am not really familiar with all the possibilities admins have when
> setting filtering for different consoles but KERN_NO_CONSOLES sounds
> rather alien to the existing priority based approach.

KERN_NO_CONSOLES is not a priority based approach.
KERN_NO_CONSOLES resembles CONSOLE_LOGLEVEL_SILENT.

>                                                       You can fine tune
> priorities and that is all right because they should be reflecting
> importance.

Developer's importance and administrator's interests are different. Any printk()
user is randomly selecting KERN_$LEVEL. Administrators are swayed by having to
record the lowest priority from all interested messages.

>             But global no-consoles doesn't really fit in here because
> each console might require a different policy but the marking is
> unconditional and largely unaware of existing consoles.

Why unconditional? I'm saying that users of KERN_NO_CONSOLES marking (in other
words, "whether the message is good enough for console or not") should be
configurable via e.g. sysctl. If administrators want to use per-console loglevel
setting, they can tell the kernel not to mark KERN_NO_CONSOLES via e.g. sysctl.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-28 11:33       ` Tetsuo Handa
  2020-04-28 12:18         ` Michal Hocko
@ 2020-05-06  9:45         ` Tetsuo Handa
  2020-05-06 15:26           ` Joe Perches
  1 sibling, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-06  9:45 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek
  Cc: Steven Rostedt, linux-kernel, Dmitry Safonov, Michal Hocko, Yafang Shao

On 2020/04/28 20:33, Tetsuo Handa wrote:
> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>>> important but "printed for immediate notification" is not important.
>>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
>>> immediate notification" is important.
>>
>> per-console loglevel is a user configurable parameter.
>> KERN_NO_CONSOLES is a hard-coded policy.
> 
> But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
> KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
> 

Any problems remaining?

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-06  9:45         ` Tetsuo Handa
@ 2020-05-06 15:26           ` Joe Perches
  2020-05-07  0:50             ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Joe Perches @ 2020-05-06 15:26 UTC (permalink / raw)
  To: Tetsuo Handa, Sergey Senozhatsky, Petr Mladek
  Cc: Steven Rostedt, linux-kernel, Dmitry Safonov, Michal Hocko, Yafang Shao

On Wed, 2020-05-06 at 18:45 +0900, Tetsuo Handa wrote:
> On 2020/04/28 20:33, Tetsuo Handa wrote:
> > On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> > > > KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
> > > > important but "printed for immediate notification" is not important.
> > > > In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
> > > > immediate notification" is important.
> > > 
> > > per-console loglevel is a user configurable parameter.
> > > KERN_NO_CONSOLES is a hard-coded policy.
> > 
> > But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
> > KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
> > 
> 
> Any problems remaining?

printk_get_level / printk_skip_level and the various
uses of %pV using printk_get_level


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-06 15:26           ` Joe Perches
@ 2020-05-07  0:50             ` Tetsuo Handa
  2020-05-07  1:02               ` Joe Perches
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-07  0:50 UTC (permalink / raw)
  To: Joe Perches
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Michal Hocko, Yafang Shao

On 2020/05/07 0:26, Joe Perches wrote:
> On Wed, 2020-05-06 at 18:45 +0900, Tetsuo Handa wrote:
>> On 2020/04/28 20:33, Tetsuo Handa wrote:
>>> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>>>>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>>>>> important but "printed for immediate notification" is not important.
>>>>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
>>>>> immediate notification" is important.
>>>>
>>>> per-console loglevel is a user configurable parameter.
>>>> KERN_NO_CONSOLES is a hard-coded policy.
>>>
>>> But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
>>> KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
>>>
>>
>> Any problems remaining?
> 
> printk_get_level / printk_skip_level and the various
> uses of %pV using printk_get_level
> 

Excuse me, but what do you mean?

I wish printk() accepts "loglevel" argument detached from "fmt" argument (e.g.

  int printkl(int loglevel, const char *fmt_without_loglevel, ...);
  int vprintkl(int loglevel, const char *fmt_without_loglevel, va_list args);

) so that users of KERN_NO_CONSOLES need not to do like

  if (sysctl_no_console_for_XX)
    printk(KERN_INFO KERN_NO_CONSOLES pr_fmt(fmt) "%s\n", "hello");
  else
    printk(KERN_INFO pr_fmt(fmt) "%s\n", "hello");

or

  printk("%s" pr_fmt(fmt) "%s\n", sysctl_no_console_for_XX ? KERN_INFO KERN_NO_CONSOLES : KERN_INFO, "hello");

in order to conditionally embed KERN_NO_CONSOLES into

  pr_info("%s\n", "hello");

. But this patch is about whether KERN_NO_CONSOLES is acceptable. How to
pass KERN_NO_CONSOLES (if KERN_NO_CONSOLES is acceptable) is a future patch.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-07  0:50             ` Tetsuo Handa
@ 2020-05-07  1:02               ` Joe Perches
  2020-05-07  5:13                 ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Joe Perches @ 2020-05-07  1:02 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Michal Hocko, Yafang Shao

On Thu, 2020-05-07 at 09:50 +0900, Tetsuo Handa wrote:
> On 2020/05/07 0:26, Joe Perches wrote:
> > On Wed, 2020-05-06 at 18:45 +0900, Tetsuo Handa wrote:
> > > On 2020/04/28 20:33, Tetsuo Handa wrote:
> > > > On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> > > > > > KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
> > > > > > important but "printed for immediate notification" is not important.
> > > > > > In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
> > > > > > immediate notification" is important.
> > > > > 
> > > > > per-console loglevel is a user configurable parameter.
> > > > > KERN_NO_CONSOLES is a hard-coded policy.
> > > > 
> > > > But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
> > > > KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
> > > > 
> > > 
> > > Any problems remaining?
> > 
> > printk_get_level / printk_skip_level and the various
> > uses of %pV using printk_get_level
> > 
> 
> Excuse me, but what do you mean?
> 
> I wish printk() accepts "loglevel" argument detached from "fmt" argument (e.g.

I think that's a bad idea as it would expand
_every_ use of printk with another argument
and overall code size would increase for very
little value.

And do look at the code and uses of printk_get_level.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-07  1:02               ` Joe Perches
@ 2020-05-07  5:13                 ` Tetsuo Handa
  2020-05-07  5:30                   ` Joe Perches
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-07  5:13 UTC (permalink / raw)
  To: Joe Perches
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Michal Hocko, Yafang Shao

On 2020/05/07 10:02, Joe Perches wrote:
>>> printk_get_level / printk_skip_level and the various
>>> uses of %pV using printk_get_level
>>>
>>
>> Excuse me, but what do you mean?
>>
>> I wish printk() accepts "loglevel" argument detached from "fmt" argument (e.g.
> 
> I think that's a bad idea as it would expand
> _every_ use of printk with another argument
> and overall code size would increase for very
> little value.

I'm not saying that we should add loglevel argument to all printk() callers.
I'm saying that we could add a variant of printk() which accepts loglevel
argument (say, e.g. printkl() and vprintkl()).

I think that some of printk_get_level() users are using printk_get_level() only
for detaching loglevel argument from fmt argument.

For example, fs/f2fs/f2fs.h defines f2fs_{err,warn,notice,info,debug}() which pass
KERN_* to f2fs_printk(), but f2fs_printk() in fs/f2fs/super.c trims KERN_* and passes
it back to printk(). If printkl() were there, f2fs_err() etc. can directly call
printkl() (and avoids printk_get_level(), printk_skip_level() and "struct va_format").

fs/btrfs/ctree.h similarly defines btrfs_{emerg,alert,crit,err,warn,notice,info}() and
their RCU and latelimited variants which pass KERN_* to btrfs_printk(), but
btrfs_printk() in fs/btrfs/super.c trims KERN_* and passes it back to printk().
If printkl() were there, btrfs_emerg() etc. can avoid printk_get_level() and
printk_skip_level().

sound/core/misc.c defines __snd_printk() which allows inserting filename and line number.
If printkl() were there, __snd_printk() can avoid printk_get_level() and printk_skip_level(),
and can constify format argument variable (which is currently writable just in order to embed
loglevel argument).

I don't know how the lockless logbuf will replace printk_safe_flush_buffer(). But I guess
it is possible to avoid printk_safe_flush_buffer() and printk_skip_level() as demonstrated
by https://lkml.kernel.org/r/5e192ca2-3b24-0b45-fc13-51feec43c216@i-love.sakura.ne.jp .

Then, printk_skip_headers() will be the only user of printk_skip_level(). I don't know how
vkdb_printf() works, but vkdb_printf() is currently using printk_skip_level() in order to
remove loglevel argument. We can avoid printk_skip_level() if loglevel argument is detached
 from fmt argument.

> 
> And do look at the code and uses of printk_get_level.

And again, what am I missing?


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-07  5:13                 ` Tetsuo Handa
@ 2020-05-07  5:30                   ` Joe Perches
  2020-05-07  5:39                     ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Joe Perches @ 2020-05-07  5:30 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Michal Hocko, Yafang Shao

On Thu, 2020-05-07 at 14:13 +0900, Tetsuo Handa wrote:
> On 2020/05/07 10:02, Joe Perches wrote:
> > > > printk_get_level / printk_skip_level and the various
> > > > uses of %pV using printk_get_level
> > > > 
> > > 
> > > Excuse me, but what do you mean?
> > > 
> > > I wish printk() accepts "loglevel" argument detached from "fmt" argument (e.g.
> > 
> > I think that's a bad idea as it would expand
> > _every_ use of printk with another argument
> > and overall code size would increase for very
> > little value.
> 
> I'm not saying that we should add loglevel argument to all printk() callers.
> I'm saying that we could add a variant of printk() which accepts loglevel
> argument (say, e.g. printkl() and vprintkl()).
> 
> I think that some of printk_get_level() users are using printk_get_level() only
> for detaching loglevel argument from fmt argument.

I believe wrote all of those.

> I don't know how the lockless logbuf will replace printk_safe_flush_buffer(). But I guess
> it is possible to avoid printk_safe_flush_buffer() and printk_skip_level() as demonstrated
> by https://lkml.kernel.org/r/5e192ca2-3b24-0b45-fc13-51feec43c216@i-love.sakura.ne.jp .
> 
> Then, printk_skip_headers() will be the only user of printk_skip_level(). I don't know how
> vkdb_printf() works, but vkdb_printf() is currently using printk_skip_level() in order to
> remove loglevel argument. We can avoid printk_skip_level() if loglevel argument is detached
>  from fmt argument.

a vprintk_emit variant would probably do.

I proposed awhile back making functions for pr_<level>
https://lore.kernel.org/lkml/1466739971-30399-1-git-send-email-joe@perches.com/

Maybe it's time for that and something appropriate
like it for your next use too.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-07  5:30                   ` Joe Perches
@ 2020-05-07  5:39                     ` Tetsuo Handa
  0 siblings, 0 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-07  5:39 UTC (permalink / raw)
  To: Joe Perches, Sergey Senozhatsky, Petr Mladek
  Cc: Steven Rostedt, linux-kernel, Dmitry Safonov, Michal Hocko, Yafang Shao

On 2020/05/07 14:30, Joe Perches wrote:
> I proposed awhile back making functions for pr_<level>
> https://lore.kernel.org/lkml/1466739971-30399-1-git-send-email-joe@perches.com/

Great. That will also benefit KERN_NO_CONSOLES.

> 
> Maybe it's time for that and something appropriate
> like it for your next use too.

How to pass KERN_NO_CONSOLES (if KERN_NO_CONSOLES is acceptable) is a future patch.
I believe that there is no remaining problem regarding KERN_NO_CONSOLES itself.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-04-29 16:35                   ` Tetsuo Handa
@ 2020-05-13  6:26                     ` Sergey Senozhatsky
  2020-05-13  7:58                       ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Sergey Senozhatsky @ 2020-05-13  6:26 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Michal Hocko, Sergey Senozhatsky, Petr Mladek, Steven Rostedt,
	linux-kernel, Dmitry Safonov, Yafang Shao

On (20/04/30 01:35), Tetsuo Handa wrote:
> Below is the default rules for rsyslog-8.24.0-52.el7 (userspace syslog daemon).
> Of course administrators can modify as needed, but notice that KERN_INFO is saved
> to /var/log/messages but KERN_DEBUG is saved to nowhere.
> 
> ----------
> # Log all kernel messages to the console.
> # Logging much else clutters up the screen.
> #kern.*                                                 /dev/console
> 
> # Log anything (except mail) of level info or higher.
> # Don't log private authentication messages!
> *.info;mail.none;authpriv.none;cron.none                /var/log/messages
> 
> # The authpriv file has restricted access.
> authpriv.*                                              /var/log/secure
> 
> # Log all the mail messages in one place.
> mail.*                                                  -/var/log/maillog
> 
> 
> # Log cron stuff
> cron.*                                                  /var/log/cron
> 
> # Everybody gets emergency messages
> *.emerg                                                 :omusrmsg:*
> 
> # Save news errors of level crit and higher in a special file.
> uucp,news.crit                                          /var/log/spooler
> 
> # Save boot messages also to boot.log
> local7.*                                                /var/log/boot.log
> ----------

Yes, but this looks like it's the consumer of the messages who
decides what to filter and what not to. rsyslog, dmesg, etc.
will have different filtering policies. It's not like the kernel
decides what to hide and what to show. If would compare this to
NO_CONSOLES, then NO_CONSOLES does a different thing after all.

	-ss

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13  6:26                     ` Sergey Senozhatsky
@ 2020-05-13  7:58                       ` Tetsuo Handa
  2020-05-13 10:04                         ` Petr Mladek
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-13  7:58 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Michal Hocko, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/05/13 15:26, Sergey Senozhatsky wrote:
> Yes, but this looks like it's the consumer of the messages who
> decides what to filter and what not to. rsyslog, dmesg, etc.
> will have different filtering policies. It's not like the kernel
> decides what to hide and what to show. If would compare this to
> NO_CONSOLES, then NO_CONSOLES does a different thing after all.

I just showed an example that changing dump_tasks() messages from
KERN_INFO to KERN_DEBUG is not an option. If dump_tasks() were using
KERN_DEBUG, the consumer of the messages will have to receive all
KERN_DEBUG messages, which needlessly contains uninterested messages.
If dump_tasks() allows use of NO_CONSOLES (via e.g. sysctl switch),
the consumer does not need to receive KERN_DEBUG messages.

What is wrong with adding NO_CONSOLES ?

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  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:03                           ` Tetsuo Handa
  0 siblings, 2 replies; 44+ messages in thread
From: Petr Mladek @ 2020-05-13 10:04 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Michal Hocko, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Wed 2020-05-13 16:58:48, Tetsuo Handa wrote:
> On 2020/05/13 15:26, Sergey Senozhatsky wrote:
> > Yes, but this looks like it's the consumer of the messages who
> > decides what to filter and what not to. rsyslog, dmesg, etc.
> > will have different filtering policies. It's not like the kernel
> > decides what to hide and what to show. If would compare this to
> > NO_CONSOLES, then NO_CONSOLES does a different thing after all.
> 
> I just showed an example that changing dump_tasks() messages from
> KERN_INFO to KERN_DEBUG is not an option. If dump_tasks() were using
> KERN_DEBUG, the consumer of the messages will have to receive all
> KERN_DEBUG messages, which needlessly contains uninterested messages.
> If dump_tasks() allows use of NO_CONSOLES (via e.g. sysctl switch),
> the consumer does not need to receive KERN_DEBUG messages.
> 
> 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


The console loglevel handling is already very complicated. The
behavior is affected by:

  + four values in console_printk array:
      + console_loglevel
      + default_message_loglevel
      + minimum_console_loglevel
      + default_console_loglevel

  + ignore_loglevel variable

  + loglevel assigned to each message


I really do not see a reason for another loglevel, another sysfs
interface, and another special handling. It would just make it even
more complicated for both developers and users.

What is so special about  OOM dump task so that it would deserve such
complications?

The dump might already be enabled or disabled. If is not important
enough to reach the console then the messages should be printed
with a lower loglevel.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 10:04                         ` Petr Mladek
@ 2020-05-13 10:49                           ` Michal Hocko
  2020-05-13 11:24                             ` Tetsuo Handa
  2020-05-13 11:03                           ` Tetsuo Handa
  1 sibling, 1 reply; 44+ messages in thread
From: Michal Hocko @ 2020-05-13 10:49 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Tetsuo Handa, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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?

Nothing really. Except for the potential amount of the output. But as
you've said there are two ways around that. Disable this output if you
do not need it or make it a lower loglevel. A completely different
method of tagging messages just to distinguish different backends of the
printk ring buffers sounds like a bad idea to me because it a) adds a
policy to the kernel and b) it makes it incredibly hard to judge when to
use such a feature. I simply cannot tell whether somebody considers
dump_tasks an important information to be printed on consoles.

If there is any need to control which messages should be routed to which
backend then the proper solution would be to filter messages per log
level per backend. But I have no idea how feasible this is for the
existing infrastructure - or maybe it already exists...
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 10:04                         ` Petr Mladek
  2020-05-13 10:49                           ` Michal Hocko
@ 2020-05-13 11:03                           ` Tetsuo Handa
  2020-05-13 12:34                             ` Petr Mladek
                                               ` (2 more replies)
  1 sibling, 3 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-13 11:03 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Michal Hocko, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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

> What is so special about  OOM dump task so that it would deserve such
> complications?

OOM dump task is special in that it can generate thousands of KERN_INFO
messages. If such messages are printed to consoles, it defers solving OOM
situation.

But setting /proc/sys/vm/oom_dump_tasks to 0 causes such messages being
not delivered to userspace daemon for later analysis. Therefore, we can not
set /proc/sys/vm/oom_dump_tasks to 0 if we want to save such messages for
later analysis.

Changing console loglevel (e.g. setting "quiet" kernel command line option)
in order to hide such messages also prevents all other KERN_INFO messages from
being printed to consoles. Since some KERN_INFO messages are worth printing to
consoles while other KERN_INFO messages are worth printing to consoles,
controlling with

>   + loglevel assigned to each message

is inevitable.

I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
printing to consoles and the rest messages do not worth printing to consoles.
Existing KERN_$LOGLEVEL is too rough-grained.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 10:49                           ` Michal Hocko
@ 2020-05-13 11:24                             ` Tetsuo Handa
  2020-05-13 12:19                               ` Petr Mladek
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-13 11:24 UTC (permalink / raw)
  To: Michal Hocko, Petr Mladek
  Cc: Sergey Senozhatsky, Steven Rostedt, linux-kernel, Dmitry Safonov,
	Yafang Shao

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?
> 
> Nothing really. Except for the potential amount of the output.

"echo t > /proc/sysrq-trigger" from userspace program is another example.

> But as
> you've said there are two ways around that. Disable this output if you
> do not need it or make it a lower loglevel. 

Disable this output for syslog is not acceptable for me, but disable this
output for consoles is preferable for me.

> I simply cannot tell whether somebody considers
> dump_tasks an important information to be printed on consoles.

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.

> 
> If there is any need to control which messages should be routed to which
> backend then the proper solution would be to filter messages per log
> level per backend.

Possible backends will be "zero or more than zero" consoles + "zero or one"
syslog, and KERN_NO_CONSOLES is a method for force selecting "zero" console
backend.

>                    But I have no idea how feasible this is for the
> existing infrastructure - or maybe it already exists...

There is per-console loglevel proposal (which allows selecting "some" console
backends). But it is based on KERN_$LOGLEVEL which is too rough-grained.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 11:24                             ` Tetsuo Handa
@ 2020-05-13 12:19                               ` Petr Mladek
  2020-05-13 12:59                                 ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Petr Mladek @ 2020-05-13 12:19 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Michal Hocko, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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?

> There is per-console loglevel proposal (which allows selecting "some" console
> backends). But it is based on KERN_$LOGLEVEL which is too rough-grained.

IMHO, developers already have troubles to decide between the existing
8 loglevels. And it is easier because the names describe the severity.

NO_CONSOLES would be different. The effect is almost[*] clear. But only
few people would know the background why it was introduced and where
to use it.

I know that it is meant as a modifier, like LOGLEVEL_SCHED and
KERN_CONT. But this is another reason to avoid it. We already have
huge pain with these two modifiers. They both do not work well.

[*] It will have no effect when it was disabled by a sysfs knob.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 11:03                           ` Tetsuo Handa
@ 2020-05-13 12:34                             ` Petr Mladek
  2020-05-13 13:46                             ` Steven Rostedt
  2020-05-13 13:55                             ` Steven Rostedt
  2 siblings, 0 replies; 44+ messages in thread
From: Petr Mladek @ 2020-05-13 12:34 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Sergey Senozhatsky, Michal Hocko, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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.
NO_CONSOLES would mess with this decision. Some messages would suddenly
get hidden on console but appear in userspace. 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.

I am strongly against this.

Please, use the existing loglevels to hide messages on
console. Configure your filter to store them in userspace.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 12:19                               ` Petr Mladek
@ 2020-05-13 12:59                                 ` Tetsuo Handa
  2020-05-14  8:00                                   ` Petr Mladek
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-13 12:59 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Michal Hocko, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  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
  2 siblings, 1 reply; 44+ messages in thread
From: Steven Rostedt @ 2020-05-13 13:46 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, Michal Hocko, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Wed, 13 May 2020 20:03:53 +0900
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
> printing to consoles and the rest messages do not worth printing to consoles.
> Existing KERN_$LOGLEVEL is too rough-grained.

And this statement is exactly why I believe you are wrong.

Because *I* think messages to the console is more important than messages
to the logs. Several of my servers are only monitored by the console. I
seldom look at the logs on those machines.

This is a policy decision, and must be made by user space. Your use case is
not applicable to everyone else's use case. And should not be set in stone
by the kernel.

-- Steve

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 11:03                           ` Tetsuo Handa
  2020-05-13 12:34                             ` Petr Mladek
  2020-05-13 13:46                             ` Steven Rostedt
@ 2020-05-13 13:55                             ` Steven Rostedt
  2020-05-13 15:20                               ` Tetsuo Handa
  2 siblings, 1 reply; 44+ messages in thread
From: Steven Rostedt @ 2020-05-13 13:55 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Petr Mladek, Sergey Senozhatsky, Michal Hocko, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Wed, 13 May 2020 20:03:53 +0900
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
> printing to consoles and the rest messages do not worth printing to consoles.
> Existing KERN_$LOGLEVEL is too rough-grained.

Why don't you look into having a "noconsole" command line option that will
not print anything to the consoles but oops messages.

Sounds more like what you would like, and something that perhaps would be
acceptable by the larger community.

-- Steve

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 13:46                             ` Steven Rostedt
@ 2020-05-13 14:03                               ` Tetsuo Handa
  0 siblings, 0 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-13 14:03 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Sergey Senozhatsky, Michal Hocko, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/05/13 22:46, Steven Rostedt wrote:
> On Wed, 13 May 2020 20:03:53 +0900
> Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> 
>> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
>> printing to consoles and the rest messages do not worth printing to consoles.
>> Existing KERN_$LOGLEVEL is too rough-grained.
> 
> And this statement is exactly why I believe you are wrong.
> 
> Because *I* think messages to the console is more important than messages
> to the logs. Several of my servers are only monitored by the console. I
> seldom look at the logs on those machines.

As a technical staff at a support center, I can never monitor the consoles of
customer's servers. I can examine only syslog messages saved as /var/log/messages .

> 
> This is a policy decision, and must be made by user space. Your use case is
> not applicable to everyone else's use case. And should not be set in stone
> by the kernel.

My proposal does not set in stone by the kernel.
My proposal is gives users a chance to control whether to print to consoles.

On 2020/05/13 22:55, Steven Rostedt wrote:
> On Wed, 13 May 2020 20:03:53 +0900
> Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> 
>> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
>> printing to consoles and the rest messages do not worth printing to consoles.
>> Existing KERN_$LOGLEVEL is too rough-grained.
> 
> Why don't you look into having a "noconsole" command line option that will
> not print anything to the consoles but oops messages.

I can't force customers to use "noconsole" command line option. That's a
too rough-grained boolean.

> 
> Sounds more like what you would like, and something that perhaps would be
> acceptable by the larger community.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 13:55                             ` Steven Rostedt
@ 2020-05-13 15:20                               ` Tetsuo Handa
  0 siblings, 0 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-13 15:20 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Sergey Senozhatsky, Michal Hocko, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/05/13 22:55, Steven Rostedt wrote:
> On Wed, 13 May 2020 20:03:53 +0900
> Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> 
>> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
>> printing to consoles and the rest messages do not worth printing to consoles.
>> Existing KERN_$LOGLEVEL is too rough-grained.
> 
> Why don't you look into having a "noconsole" command line option that will
> not print anything to the consoles but oops messages.

Well, such global option can be as harmful as "ignore_loglevel" command line
option in that we have to worry about how per-console loglevel can co-exist.

The idea of per-console loglevel is to allow specifying different threshold
based on characteristics of each console while the effect of ignore_loglevel
is to disallow specifying different threshold. (I'm wondering whether
ignore_loglevel should be valid under CONSOLE_LOGLEVEL_SILENT, for
CONSOLE_LOGLEVEL_SILENT says "don't print to consoles" while ignore_loglevel
says "always print to consoles".)

If we want to implement per-console loglevel in the future, shouldn't we first
deprecate the conflicting "ignore_loglevel" command line option (and get rid
of it by asking users to use LOGLEVEL_DEBUG as console loglevel)?

The idea of "noconsole" command line option is to disallow printing almost all
messages regardless of KERN_$LOGLEVEL while the idea of per-console loglevel is
to allow printing some messages based on KERN_$LOGLEVEL.

> 
> Sounds more like what you would like, and something that perhaps would be
> acceptable by the larger community.

More we introduce global switches, more difficult to introduce fine-grained
switches (e.g. per-console loglevel).

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-13 12:59                                 ` Tetsuo Handa
@ 2020-05-14  8:00                                   ` Petr Mladek
  2020-05-14 11:23                                     ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Petr Mladek @ 2020-05-14  8:00 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Michal Hocko, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-14  8:00                                   ` Petr Mladek
@ 2020-05-14 11:23                                     ` Tetsuo Handa
  2020-05-14 16:26                                       ` Petr Mladek
  0 siblings, 1 reply; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-14 11:23 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Michal Hocko, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

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.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-14 11:23                                     ` Tetsuo Handa
@ 2020-05-14 16:26                                       ` Petr Mladek
  2020-05-14 23:24                                         ` Tetsuo Handa
  0 siblings, 1 reply; 44+ messages in thread
From: Petr Mladek @ 2020-05-14 16:26 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Michal Hocko, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On Thu 2020-05-14 20:23:55, Tetsuo Handa wrote:
> 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".

This does not make much sense to me. KERN_NO_CONSOLES would be another
global flag. If you enable/disable its functionality, it would affect
all strings with this flag (not only the ones used by OOM killer).

I am not going to comment the rest. We are going in circles and I do
not know how to better explain my concerns.


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

One problem there is a lack of reviewers.

Best Regards
Petr

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH] printk: Add loglevel for "do not print to consoles".
  2020-05-14 16:26                                       ` Petr Mladek
@ 2020-05-14 23:24                                         ` Tetsuo Handa
  0 siblings, 0 replies; 44+ messages in thread
From: Tetsuo Handa @ 2020-05-14 23:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Michal Hocko, Sergey Senozhatsky, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Yafang Shao

On 2020/05/15 1:26, Petr Mladek wrote:
> This does not make much sense to me. KERN_NO_CONSOLES would be another
> global flag. If you enable/disable its functionality, it would affect
> all strings with this flag (not only the ones used by OOM killer).

Are you assuming that the switch is applied on KERN_$LEVEL setting (e.g.

  /proc/sys/kernel/print_emerg_messages_on_consoles
  /proc/sys/kernel/print_alert_messages_on_consoles
  /proc/sys/kernel/print_crit_messages_on_consoles
  /proc/sys/kernel/print_err_messages_on_consoles
  /proc/sys/kernel/print_warning_messages_on_consoles
  /proc/sys/kernel/print_notice_messages_on_consoles
  /proc/sys/kernel/print_info_messages_on_consoles
  /proc/sys/kernel/print_debug_messages_on_consoles

) ? Then, that is not what I'm proposing.

The switch I will propose is applied on individual printk() call (e.g.

  printk("%s[%7d] %5d %5d %8lu %8lu %8ld %8lu         %5hd %s\n",
         sysctl_oom_dump_tasks == 2 ? KERN_INFO KERN_NO_CONSOLES : KERN_INFO,
         task->pid, from_kuid(&init_user_ns, task_uid(task)),
         task->tgid, task->mm->total_vm, get_mm_rss(task->mm),
         mm_pgtables_bytes(task->mm),
         get_mm_counter(task->mm, MM_SWAPENTS),
         task->signal->oom_score_adj, task->comm);

) which is NOT another global flag.

Since Dmitry Safonov is working on adding loglevel argument to show_stack(),
we will also be able to implement dump_stack_loglvl(const char *loglvl). Thus,
we will be able to apply KERN_NO_CONSOLES flags to e.g. only dump_stack() /
show_mem() / dump_tasks() etc. WITHOUT MAKING THE SWITCHES GLOBAL.
The direction is heading for "+ loglevel assigned to each message".

^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2020-05-14 23:25 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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