[PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Hans de Goede]

The goal of passing the "quiet" option to the kernel is for the kernel
to be quiet unless something really is wrong.

Sofar passing quiet has been (mostly) equivalent to passing
loglevel=4 on the kernel commandline. Which means to show any messages
with a level of KERN_ERR or higher severity on the console.

In practice this often does not result in a quiet boot though, since
there are many false-positive or otherwise harmless error messages printed,
defeating the purpose of the quiet option. Esp. the ACPICA code is really
bad wrt this, but there are plenty of others too.

This commit makes CONSOLE_LOGLEVEL_QUIET configurable.

This for example will allow distros which want quiet to really mean quiet
to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
of whack-a-mole silencing harmless error messages.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 include/linux/printk.h |  6 +++---
 lib/Kconfig.debug      | 11 +++++++++++
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 6d7e800affd8..18602bb3eca8 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -50,15 +50,15 @@ static inline const char *printk_skip_headers(const char *buffer)
 /* We show everything that is MORE important than this.. */
 #define CONSOLE_LOGLEVEL_SILENT  0 /* Mum's the word */
 #define CONSOLE_LOGLEVEL_MIN	 1 /* Minimum loglevel we let people use */
-#define CONSOLE_LOGLEVEL_QUIET	 4 /* Shhh ..., when booted with "quiet" */
 #define CONSOLE_LOGLEVEL_DEBUG	10 /* issue debug messages */
 #define CONSOLE_LOGLEVEL_MOTORMOUTH 15	/* You can't shut this one up */
 
 /*
- * Default used to be hard-coded at 7, we're now allowing it to be set from
- * kernel config.
+ * Default used to be hard-coded at 7, quiet used to be hardcoded at 4,
+ * we're now allowing both to be set from kernel config.
  */
 #define CONSOLE_LOGLEVEL_DEFAULT CONFIG_CONSOLE_LOGLEVEL_DEFAULT
+#define CONSOLE_LOGLEVEL_QUIET	 CONFIG_CONSOLE_LOGLEVEL_QUIET
 
 extern int console_printk[];
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8838d1158d19..0d1c48dd22a9 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -30,6 +30,17 @@ config CONSOLE_LOGLEVEL_DEFAULT
 	  usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT
 	  option.
 
+config CONSOLE_LOGLEVEL_QUIET
+	int "quiet console loglevel (1-15)"
+	range 1 15
+	default "4"
+	help
+	  loglevel to use when "quiet" is passed on the kernel commandline.
+
+	  When "quiet" is passed on the kernel commandline this loglevel
+	  will be used as the loglevel. IOW passing "quiet" will be the
+	  equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>"
+
 config MESSAGE_LOGLEVEL_DEFAULT
 	int "Default message log level (1-7)"
 	range 1 7
-- 
2.17.1

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Steven Rostedt]

On Tue, 19 Jun 2018 13:57:26 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> The goal of passing the "quiet" option to the kernel is for the kernel
> to be quiet unless something really is wrong.
> 
> Sofar passing quiet has been (mostly) equivalent to passing
> loglevel=4 on the kernel commandline. Which means to show any messages
> with a level of KERN_ERR or higher severity on the console.
> 
> In practice this often does not result in a quiet boot though, since
> there are many false-positive or otherwise harmless error messages printed,
> defeating the purpose of the quiet option. Esp. the ACPICA code is really
> bad wrt this, but there are plenty of others too.
> 
> This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
> 
> This for example will allow distros which want quiet to really mean quiet
> to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
> then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
> of whack-a-mole silencing harmless error messages.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Sergey Senozhatsky]

On (06/19/18 09:31), Steven Rostedt wrote:
> > The goal of passing the "quiet" option to the kernel is for the kernel
> > to be quiet unless something really is wrong.
> > 
> > Sofar passing quiet has been (mostly) equivalent to passing
> > loglevel=4 on the kernel commandline. Which means to show any messages
> > with a level of KERN_ERR or higher severity on the console.
> > 
> > In practice this often does not result in a quiet boot though, since
> > there are many false-positive or otherwise harmless error messages printed,
> > defeating the purpose of the quiet option. Esp. the ACPICA code is really
> > bad wrt this, but there are plenty of others too.
> > 
> > This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
> > 
> > This for example will allow distros which want quiet to really mean quiet
> > to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
> > then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
> > of whack-a-mole silencing harmless error messages.
> > 
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Looks OK to me

Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

	-ss

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Petr Mladek]

On Tue 2018-06-19 13:57:26, Hans de Goede wrote:
> The goal of passing the "quiet" option to the kernel is for the kernel
> to be quiet unless something really is wrong.
> 
> Sofar passing quiet has been (mostly) equivalent to passing
> loglevel=4 on the kernel commandline. Which means to show any messages
> with a level of KERN_ERR or higher severity on the console.
> 
> In practice this often does not result in a quiet boot though, since
> there are many false-positive or otherwise harmless error messages printed,
> defeating the purpose of the quiet option. Esp. the ACPICA code is really
> bad wrt this, but there are plenty of others too.

I see your pain. But this sounds like a workaround for a broken code.
This change might just encourage people to create even more mess.


> This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
> 
> This for example will allow distros which want quiet to really mean quiet
> to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
> then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
> of whack-a-mole silencing harmless error messages.

I find it a bit confusing that "quiet" would mean something different
on different systems.

Why did not you use loglevel=<whatever_you_need> instead of "quiet"?

Alternative solution would be to add "silent" or so to calm down
everything. But I am afraid that any change in this area would
just create a mess similar to grep -s and -q options.


Best Regards,
Petr

PS: I will not block it if Steven and Sergey are fine with this. But
I want to be sure that they considered the above views. It looked like
a no-brainer to me at the beginning. I even pushed this to printk.git.
But the pushing gave me some more time to think about it...

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Sergey Senozhatsky]

On (06/20/18 13:03), Petr Mladek wrote:
> > This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
> > 
> > This for example will allow distros which want quiet to really mean quiet
> > to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
> > then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
> > of whack-a-mole silencing harmless error messages.
> 
> I find it a bit confusing that "quiet" would mean something different
> on different systems.

Good that you brought this up. I had similar feelings but then the
patch looked rather simple and I kinda agreed with it. If we can come
up with alternative solution (you mentioned some) then it would be
great.

	-ss

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Hans de Goede]

Hi,

On 20-06-18 13:03, Petr Mladek wrote:
> On Tue 2018-06-19 13:57:26, Hans de Goede wrote:
>> The goal of passing the "quiet" option to the kernel is for the kernel
>> to be quiet unless something really is wrong.
>>
>> Sofar passing quiet has been (mostly) equivalent to passing
>> loglevel=4 on the kernel commandline. Which means to show any messages
>> with a level of KERN_ERR or higher severity on the console.
>>
>> In practice this often does not result in a quiet boot though, since
>> there are many false-positive or otherwise harmless error messages printed,
>> defeating the purpose of the quiet option. Esp. the ACPICA code is really
>> bad wrt this, but there are plenty of others too.
> 
> I see your pain. But this sounds like a workaround for a broken code.
> This change might just encourage people to create even more mess.

I've been submitting patches upstream to fix false-positive KERN_ERR
messages for more then a year now and getting a KERN_ERR free kernel
(on more then 1 specific model hw) is just undoable. Every release some
new nonsense error comes up, like e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=1568276

Besides this random KERN_ERR cases (of which there are plenty
by themselves) I've also had long discussions with the ACPICA upstream
maintainers, but they refuse to change this instead insisting that:

a) Vendors should fix there DSDTs to be perfect; and
b) end-users should then update their BIOS to fix this

Neither of which is a realistic expectation in anyway.

IOW I've tried to fix this the right way and I will keep posting patches
to keep "dmesg --level=err" output to a minimum, but it simply is not
feasible to get the desired quiet boot with its current configuration
of quiet mapping to loglevel=4.

>> This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
>>
>> This for example will allow distros which want quiet to really mean quiet
>> to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
>> then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
>> of whack-a-mole silencing harmless error messages.
> 
> I find it a bit confusing that "quiet" would mean something different
> on different systems.

The kernel is so configurable already that I don't think this really is much
of an issue, quiet will still mean quiet on all systems, some might just
be a tad more quiet (or actually be quiet) compared to others.

The same argument could be made for the default loglevel being configurable,
yet it is configurable already.

> Why did not you use loglevel=<whatever_you_need> instead of "quiet"?

We would still need to pass quiet, to also silence e.g. the messages
from the EDD code, see arch/x86/boot/edd.c around line 147 and further,
so then we would need to pass:

quiet loglevel=3

And we would need to pass it in that order! which is ugly also this
complicates giving people instructions to turn it off to debug
system not-booting problems.

> Alternative solution would be to add "silent" or so to calm down
> everything. But I am afraid that any change in this area would
> just create a mess similar to grep -s and -q options.

A better alternative would be to make quiet actually does what the
name suggests and simply unconditionally change
CONSOLE_LOGLEVEL_QUIET from 4 to 3. I went with making this configurable
because I expect that to be a controversial change.

A third, sucky, alternative would be for Fedora to permanently
carry a downstream patch changing the CONSOLE_LOGLEVEL_QUIET from 4
to 3 in printk.h. That would still lead to the confusion about quiet
not meaning the same everywhere (although I would expect e.g. Ubuntu
to follow suit) combined with extra downstream patches which are never
good.

Regards,

Hans

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Hans de Goede]

Hi,

On 20-06-18 13:24, Sergey Senozhatsky wrote:
> On (06/20/18 13:03), Petr Mladek wrote:
>>> This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
>>>
>>> This for example will allow distros which want quiet to really mean quiet
>>> to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
>>> then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
>>> of whack-a-mole silencing harmless error messages.
>>
>> I find it a bit confusing that "quiet" would mean something different
>> on different systems.
> 
> Good that you brought this up. I had similar feelings but then the
> patch looked rather simple and I kinda agreed with it. If we can come
> up with alternative solution (you mentioned some) then it would be
> great.

I guess with my downstream hat on that we could live with silent,
but I would much prefer changing quiet, also so that we can lower
the firehose of mostly false-positive bugs coming in because of this.
Here is a short list from quick search which in no way is complete
(tip of the iceberg really):

   1413342 - Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOU
   1415853 - ACPI Error: Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-
   1514937 - ACPI Error: AE_NOT_FOUND
   1527870 - ACPI Error: [\_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND
   1552580 - ACPI Error: Method parse/execution failed
   1553320 - Kernel errors at bootup -- system runs okay
   1556967 - ACPI Error: [SMIC] Namespace lookup failure, AE_ALREADY_EXISTS
   1582825 - ACPI Error: Method parse/execution failed
   https://bugzilla.kernel.org/show_bug.cgi?id=109511
   https://bugzilla.kernel.org/show_bug.cgi?id=194687

If we change quiet to filter these out, all of these will go away, if
we add a new silent option then only fresh installs will get the
new silent option and the benefit will be much reduced.

Besides that we would also need to make e.g. arch/x86/boot/edd.c
check for both quiet and silent and of course init/main.c and probably
others too, so form a code complexity pov the Kconfig way seems better too.

Regards,

Hans

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Steven Rostedt]

On Wed, 20 Jun 2018 13:03:35 +0200
Petr Mladek <pmladek@suse.com> wrote:

> I find it a bit confusing that "quiet" would mean something different
> on different systems.

I disagree. "quiet" to me is for people that really don't care to see
anything from the kernel except for real issues that they need to
report. The first thing that I do, and many other kernel developers I
know, when installing a new distro, is to remove the "quiet" from the
command line. Because *I* care about the output.


> 
> Why did not you use loglevel=<whatever_you_need> instead of "quiet"?
> 
> Alternative solution would be to add "silent" or so to calm down
> everything. But I am afraid that any change in this area would
> just create a mess similar to grep -s and -q options.
> 
> 
> Best Regards,
> Petr
> 
> PS: I will not block it if Steven and Sergey are fine with this. But
> I want to be sure that they considered the above views. It looked like
> a no-brainer to me at the beginning. I even pushed this to printk.git.
> But the pushing gave me some more time to think about it...

I prefer this patch over adding yet another kernel command line command
that will just add to the confusion. I can imagine people saying
"what's the difference between 'quiet' and 'silent'?". I would.

I think having it as a config option is the perfect solution. I imagine
that as soon as Red Hat changes the meaning of "quiet" so will all the
other distros. The alternative is for the distros to add a patch to
make the change, which honestly is a worse solution.

I've only seen "quiet" added by distros and not by average developers.
I don't think adding this option will be confusing to anyone that
tinkers with kernel command lines anyway.

I'm for the patch.

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


-- Steve

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Takashi Iwai]

On Wed, 20 Jun 2018 16:07:53 +0200,
Steven Rostedt wrote:
> 
> On Wed, 20 Jun 2018 13:03:35 +0200
> Petr Mladek <pmladek@suse.com> wrote:
> 
> > I find it a bit confusing that "quiet" would mean something different
> > on different systems.
> 
> I disagree. "quiet" to me is for people that really don't care to see
> anything from the kernel except for real issues that they need to
> report. The first thing that I do, and many other kernel developers I
> know, when installing a new distro, is to remove the "quiet" from the
> command line. Because *I* care about the output.
> 
> 
> > 
> > Why did not you use loglevel=<whatever_you_need> instead of "quiet"?
> > 
> > Alternative solution would be to add "silent" or so to calm down
> > everything. But I am afraid that any change in this area would
> > just create a mess similar to grep -s and -q options.
> > 
> > 
> > Best Regards,
> > Petr
> > 
> > PS: I will not block it if Steven and Sergey are fine with this. But
> > I want to be sure that they considered the above views. It looked like
> > a no-brainer to me at the beginning. I even pushed this to printk.git.
> > But the pushing gave me some more time to think about it...
> 
> I prefer this patch over adding yet another kernel command line command
> that will just add to the confusion. I can imagine people saying
> "what's the difference between 'quiet' and 'silent'?". I would.
> 
> I think having it as a config option is the perfect solution. I imagine
> that as soon as Red Hat changes the meaning of "quiet" so will all the
> other distros.

Yeah, SUSE has gathered a pile of such bug reports and complaints from
customers, too, so we'd happily follow that :)


thanks,

Takashi

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Sergey Senozhatsky]

On (06/20/18 15:43), Hans de Goede wrote:
> 
> I guess with my downstream hat on that we could live with silent,
> but I would much prefer changing quiet, also so that we can lower
> the firehose of mostly false-positive bugs coming in because of this.
> Here is a short list from quick search which in no way is complete
> (tip of the iceberg really):
> 
>   1413342 - Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOU
>   1415853 - ACPI Error: Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-
>   1514937 - ACPI Error: AE_NOT_FOUND
>   1527870 - ACPI Error: [\_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND
>   1552580 - ACPI Error: Method parse/execution failed
>   1553320 - Kernel errors at bootup -- system runs okay
>   1556967 - ACPI Error: [SMIC] Namespace lookup failure, AE_ALREADY_EXISTS
>   1582825 - ACPI Error: Method parse/execution failed
>   https://bugzilla.kernel.org/show_bug.cgi?id=109511
>   https://bugzilla.kernel.org/show_bug.cgi?id=194687
> 
> If we change quiet to filter these out, all of these will go away, if
> we add a new silent option then only fresh installs will get the
> new silent option and the benefit will be much reduced.

Hi,

No real objections from my side, I guess. Especially given that
Red Hat, VMWare and SUSE like your patch :)

	-ss

Re: [PATCH] printk: Make CONSOLE_LOGLEVEL_QUIET configurable

[Petr Mladek]

On Wed 2018-06-20 15:37:47, Hans de Goede wrote:
> Hi,
> 
> On 20-06-18 13:03, Petr Mladek wrote:
> > On Tue 2018-06-19 13:57:26, Hans de Goede wrote:
> > > The goal of passing the "quiet" option to the kernel is for the kernel
> > > to be quiet unless something really is wrong.
> > > 
> > > Sofar passing quiet has been (mostly) equivalent to passing
> > > loglevel=4 on the kernel commandline. Which means to show any messages
> > > with a level of KERN_ERR or higher severity on the console.
> > > 
> > > In practice this often does not result in a quiet boot though, since
> > > there are many false-positive or otherwise harmless error messages printed,
> > > defeating the purpose of the quiet option. Esp. the ACPICA code is really
> > > bad wrt this, but there are plenty of others too.
> > 
> > I see your pain. But this sounds like a workaround for a broken code.
> > This change might just encourage people to create even more mess.
> 
> I've been submitting patches upstream to fix false-positive KERN_ERR
> messages for more then a year now and getting a KERN_ERR free kernel
> (on more then 1 specific model hw) is just undoable. Every release some
> new nonsense error comes up, like e.g.:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1568276
> 
> Besides this random KERN_ERR cases (of which there are plenty
> by themselves) I've also had long discussions with the ACPICA upstream
> maintainers, but they refuse to change this instead insisting that:
> 
> a) Vendors should fix there DSDTs to be perfect; and
> b) end-users should then update their BIOS to fix this
> 
> Neither of which is a realistic expectation in anyway.

Thanks for the many examples. It would help me to argue if anyone
later complains about this change ;-)


> > > This commit makes CONSOLE_LOGLEVEL_QUIET configurable.
> > > 
> > > This for example will allow distros which want quiet to really mean quiet
> > > to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity
> > > then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game
> > > of whack-a-mole silencing harmless error messages.
> > 
> > I find it a bit confusing that "quiet" would mean something different
> > on different systems.
> 
> The kernel is so configurable already that I don't think this really is much
> of an issue, quiet will still mean quiet on all systems, some might just
> be a tad more quiet (or actually be quiet) compared to others.

Just for record. Some people actually do a lot to prevent adding new
configure options. The many possibilities cause troubles to users
and even experienced developers.

A common argument against adding new options is: "How users could be
able to choose reasonable value when even experts (maintainers,
developers) are not able to agree on it".


> I went with making this configurable because I expect that to
> be a controversial change.

Exactly, I thought about changing the default. But it might just
bring a lot of bike-shedding.

I do not see any other good option. More people like this patch.
So I pushed it into printk.git, branch for-4.19.

Best Regards,
Petr