* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 11:42 ` [RFC 1/2] printk: Add kernel parameter: mute_console Petr Mladek
@ 2020-10-22 13:10 ` John Ogness
2020-10-22 14:15 ` Guenter Roeck
2020-10-22 13:45 ` Steven Rostedt
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: John Ogness @ 2020-10-22 13:10 UTC (permalink / raw)
To: Petr Mladek, Sergey Senozhatsky, Steven Rostedt
Cc: Linus Torvalds, Guenter Roeck, Shreyas Joshi, shreyasjoshi15,
Greg Kroah-Hartman, Sergey Senozhatsky, linux-kernel,
Petr Mladek
On 2020-10-22, Petr Mladek <pmladek@suse.com> wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 02d4adbf98d2..52b9e7f5468d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2974,6 +2974,12 @@
> Used for mtrr cleanup. It is spare mtrr entries number.
> Set to 2 or more if your graphical card needs more.
>
> + mute_console [KNL]
> + Completely disable printing of kernel messages to
> + the console. It can still be used as stdin, stdout,
> + and stderr for the init process. Also it can be used
> + for login.
IMHO it would make more sense for this to be a console option:
console=ttyS0,115200,mute
Then other consoles could still exist that are not muted.
On a side note, I am considering proposing something similar for my
printk-rework efforts. Once console printers are moved to kthreads, some
users may not care about latencies and instead prefer synchronous
printing. My idea for this is to provide a "sync" option for the
console:
console=ttyS0,115200,sync
John Ogness
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 13:10 ` John Ogness
@ 2020-10-22 14:15 ` Guenter Roeck
2020-10-22 14:53 ` John Ogness
0 siblings, 1 reply; 15+ messages in thread
From: Guenter Roeck @ 2020-10-22 14:15 UTC (permalink / raw)
To: John Ogness, Petr Mladek, Sergey Senozhatsky, Steven Rostedt
Cc: Linus Torvalds, Shreyas Joshi, shreyasjoshi15,
Greg Kroah-Hartman, Sergey Senozhatsky, linux-kernel
On 10/22/20 6:10 AM, John Ogness wrote:
> On 2020-10-22, Petr Mladek <pmladek@suse.com> wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 02d4adbf98d2..52b9e7f5468d 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2974,6 +2974,12 @@
>> Used for mtrr cleanup. It is spare mtrr entries number.
>> Set to 2 or more if your graphical card needs more.
>>
>> + mute_console [KNL]
>> + Completely disable printing of kernel messages to
>> + the console. It can still be used as stdin, stdout,
"to all consoles"
>> + and stderr for the init process. Also it can be used
>> + for login.
>
> IMHO it would make more sense for this to be a console option:
>
> console=ttyS0,115200,mute
>
> Then other consoles could still exist that are not muted.
>
Then why specify this console in the first place ?
> On a side note, I am considering proposing something similar for my
> printk-rework efforts. Once console printers are moved to kthreads, some
> users may not care about latencies and instead prefer synchronous
> printing. My idea for this is to provide a "sync" option for the
> console:
>
> console=ttyS0,115200,sync
>
The whole point of the exercise is to disable all consoles, including default
ones which are not explicitly specified on the command line. The above would
mean that each potential console would have to be muted. That isn't really
scalable for a build system which has to handle many different console devices.
Guenter
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 14:15 ` Guenter Roeck
@ 2020-10-22 14:53 ` John Ogness
2020-10-23 11:49 ` Petr Mladek
0 siblings, 1 reply; 15+ messages in thread
From: John Ogness @ 2020-10-22 14:53 UTC (permalink / raw)
To: Guenter Roeck, Petr Mladek, Sergey Senozhatsky, Steven Rostedt
Cc: Linus Torvalds, Shreyas Joshi, shreyasjoshi15,
Greg Kroah-Hartman, Sergey Senozhatsky, linux-kernel
On 2020-10-22, Guenter Roeck <linux@roeck-us.net> wrote:
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>>> index 02d4adbf98d2..52b9e7f5468d 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -2974,6 +2974,12 @@
>>> Used for mtrr cleanup. It is spare mtrr entries number.
>>> Set to 2 or more if your graphical card needs more.
>>>
>>> + mute_console [KNL]
>>> + Completely disable printing of kernel messages to
>>> + the console. It can still be used as stdin, stdout,
>
> "to all consoles"
>
>>> + and stderr for the init process. Also it can be used
>>> + for login.
>>
>> IMHO it would make more sense for this to be a console option:
>>
>> console=ttyS0,115200,mute
>>
>> Then other consoles could still exist that are not muted.
>>
> Then why specify this console in the first place ?
Because you may still want to use it for stdin/stdout/stderr of PID 1
and/or logins. I understood "mute" as meaning the user does not want to
see kernel logging. But everything else should still work as usual.
>> On a side note, I am considering proposing something similar for my
>> printk-rework efforts. Once console printers are moved to kthreads, some
>> users may not care about latencies and instead prefer synchronous
>> printing. My idea for this is to provide a "sync" option for the
>> console:
>>
>> console=ttyS0,115200,sync
>
> The whole point of the exercise is to disable all consoles, including
> default ones which are not explicitly specified on the command line.
In that case I think specifying something like:
console=null
makes that most sense. I think implementing a "null console" driver
would be quite simple. Then there would be no need for special handling
in the printk subsystem.
John Ogness
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 14:53 ` John Ogness
@ 2020-10-23 11:49 ` Petr Mladek
2020-10-23 14:52 ` Guenter Roeck
0 siblings, 1 reply; 15+ messages in thread
From: Petr Mladek @ 2020-10-23 11:49 UTC (permalink / raw)
To: John Ogness
Cc: Guenter Roeck, Sergey Senozhatsky, Steven Rostedt,
Linus Torvalds, Shreyas Joshi, shreyasjoshi15,
Greg Kroah-Hartman, Sergey Senozhatsky, linux-kernel
On Thu 2020-10-22 16:59:15, John Ogness wrote:
> On 2020-10-22, Guenter Roeck <linux@roeck-us.net> wrote:
> > The whole point of the exercise is to disable all consoles, including
> > default ones which are not explicitly specified on the command line.
>
> In that case I think specifying something like:
>
> console=null
>
> makes that most sense. I think implementing a "null console" driver
> would be quite simple. Then there would be no need for special handling
> in the printk subsystem.
Heh, it actually already exists and has been created for exactly this
purpose, see the commit 3117ff13f104e98b05b6 ("tty: Add NULL TTY
driver").
Regarding the interface:
+ console=null or console= is OK when people do not want consoles
at all
+ mute_console (or another extra parameter) would be needed if
people wanted to have login console.
It is true that nobody asked for the login support. So, the null
console should be enough for now.
Best Regards,
Petr
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-23 11:49 ` Petr Mladek
@ 2020-10-23 14:52 ` Guenter Roeck
0 siblings, 0 replies; 15+ messages in thread
From: Guenter Roeck @ 2020-10-23 14:52 UTC (permalink / raw)
To: Petr Mladek, John Ogness
Cc: Sergey Senozhatsky, Steven Rostedt, Linus Torvalds,
Shreyas Joshi, shreyasjoshi15, Greg Kroah-Hartman,
Sergey Senozhatsky, linux-kernel
On 10/23/20 4:49 AM, Petr Mladek wrote:
> On Thu 2020-10-22 16:59:15, John Ogness wrote:
>> On 2020-10-22, Guenter Roeck <linux@roeck-us.net> wrote:
>>> The whole point of the exercise is to disable all consoles, including
>>> default ones which are not explicitly specified on the command line.
>>
>> In that case I think specifying something like:
>>
>> console=null
>>
>> makes that most sense. I think implementing a "null console" driver
>> would be quite simple. Then there would be no need for special handling
>> in the printk subsystem.
>
> Heh, it actually already exists and has been created for exactly this
> purpose, see the commit 3117ff13f104e98b05b6 ("tty: Add NULL TTY
> driver").
>
Ok with me to use that, as long as we add code that maps console=
and console=null to console=ttynull.
Guenter
> Regarding the interface:
>
> + console=null or console= is OK when people do not want consoles
> at all
>
> + mute_console (or another extra parameter) would be needed if
> people wanted to have login console.
>
> It is true that nobody asked for the login support. So, the null
> console should be enough for now.
>
> Best Regards,
> Petr
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 11:42 ` [RFC 1/2] printk: Add kernel parameter: mute_console Petr Mladek
2020-10-22 13:10 ` John Ogness
@ 2020-10-22 13:45 ` Steven Rostedt
2020-10-22 14:22 ` Guenter Roeck
2020-10-23 9:46 ` Petr Mladek
2020-10-23 0:33 ` Sergey Senozhatsky
2020-10-23 15:59 ` Linus Torvalds
3 siblings, 2 replies; 15+ messages in thread
From: Steven Rostedt @ 2020-10-22 13:45 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, John Ogness, Linus Torvalds, Guenter Roeck,
Shreyas Joshi, shreyasjoshi15, Greg Kroah-Hartman,
Sergey Senozhatsky, linux-kernel
On Thu, 22 Oct 2020 13:42:27 +0200
Petr Mladek <pmladek@suse.com> wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index fe64a49344bf..63fb96630767 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1207,6 +1207,19 @@ void __init setup_log_buf(int early)
> memblock_free(__pa(new_log_buf), new_log_buf_len);
> }
>
> +static bool mute_console;
> +
> +static int __init mute_console_setup(char *str)
> +{
> + mute_console = true;
> + pr_info("All consoles muted.\n");
> +
> + return 0;
> +}
> +
> +early_param("mute_console", mute_console_setup);
> +module_param(mute_console, bool, 0644);
> +
Why have both early_param and module_param? What's the purpose of
module_param? Usually that's there to just set a variable, without a need
for another interface. But if you have early_param() that sets
mute_console, isn't that redundant?
-- Steve
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 13:45 ` Steven Rostedt
@ 2020-10-22 14:22 ` Guenter Roeck
2020-10-23 9:46 ` Petr Mladek
1 sibling, 0 replies; 15+ messages in thread
From: Guenter Roeck @ 2020-10-22 14:22 UTC (permalink / raw)
To: Steven Rostedt, Petr Mladek
Cc: Sergey Senozhatsky, John Ogness, Linus Torvalds, Shreyas Joshi,
shreyasjoshi15, Greg Kroah-Hartman, Sergey Senozhatsky,
linux-kernel
On 10/22/20 6:45 AM, Steven Rostedt wrote:
> On Thu, 22 Oct 2020 13:42:27 +0200
> Petr Mladek <pmladek@suse.com> wrote:
>
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index fe64a49344bf..63fb96630767 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -1207,6 +1207,19 @@ void __init setup_log_buf(int early)
>> memblock_free(__pa(new_log_buf), new_log_buf_len);
>> }
>>
>> +static bool mute_console;
>> +
>> +static int __init mute_console_setup(char *str)
>> +{
>> + mute_console = true;
>> + pr_info("All consoles muted.\n");
>> +
>> + return 0;
>> +}
>> +
>> +early_param("mute_console", mute_console_setup);
>> +module_param(mute_console, bool, 0644);
>> +
>
> Why have both early_param and module_param? What's the purpose of
> module_param? Usually that's there to just set a variable, without a need
> for another interface. But if you have early_param() that sets
> mute_console, isn't that redundant?
>
For me the question was why we would need an extra module parameter
in the first place instead of just making "console=" and "console=null"
official. It doesn't really matter for us as long as "console=" is still
supported, I just don't see the point.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 13:45 ` Steven Rostedt
2020-10-22 14:22 ` Guenter Roeck
@ 2020-10-23 9:46 ` Petr Mladek
1 sibling, 0 replies; 15+ messages in thread
From: Petr Mladek @ 2020-10-23 9:46 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sergey Senozhatsky, John Ogness, Linus Torvalds, Guenter Roeck,
Shreyas Joshi, shreyasjoshi15, Greg Kroah-Hartman,
Sergey Senozhatsky, linux-kernel
On Thu 2020-10-22 09:45:12, Steven Rostedt wrote:
> On Thu, 22 Oct 2020 13:42:27 +0200
> Petr Mladek <pmladek@suse.com> wrote:
>
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index fe64a49344bf..63fb96630767 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -1207,6 +1207,19 @@ void __init setup_log_buf(int early)
> > memblock_free(__pa(new_log_buf), new_log_buf_len);
> > }
> >
> > +static bool mute_console;
> > +
> > +static int __init mute_console_setup(char *str)
> > +{
> > + mute_console = true;
> > + pr_info("All consoles muted.\n");
> > +
> > + return 0;
> > +}
> > +
> > +early_param("mute_console", mute_console_setup);
> > +module_param(mute_console, bool, 0644);
> > +
>
> Why have both early_param and module_param? What's the purpose of
> module_param? Usually that's there to just set a variable, without a need
> for another interface. But if you have early_param() that sets
> mute_console, isn't that redundant?
I was surprised as well. But both seem to be needed:
+ early_param allows to enable it on the command line.
Note that module_param would need to be set via
printk.mute_console
+ module_param() allows to modify the state at runtime
IMHO, both should be possible. It is supposed to be used similar
way like ignore_loglevel.
Best Regards,
Petr
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 11:42 ` [RFC 1/2] printk: Add kernel parameter: mute_console Petr Mladek
2020-10-22 13:10 ` John Ogness
2020-10-22 13:45 ` Steven Rostedt
@ 2020-10-23 0:33 ` Sergey Senozhatsky
2020-10-23 12:11 ` Petr Mladek
2020-10-23 15:59 ` Linus Torvalds
3 siblings, 1 reply; 15+ messages in thread
From: Sergey Senozhatsky @ 2020-10-23 0:33 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Steven Rostedt, John Ogness, Linus Torvalds,
Guenter Roeck, Shreyas Joshi, shreyasjoshi15, Greg Kroah-Hartman,
Sergey Senozhatsky, linux-kernel
On (20/10/22 13:42), Petr Mladek wrote:
> +static bool mute_console;
> +
> +static int __init mute_console_setup(char *str)
> +{
> + mute_console = true;
> + pr_info("All consoles muted.\n");
> +
> + return 0;
> +}
First of all, thanks a lot for picking this up and for the patch set!
I've several thoughts and comments below.
> static bool suppress_message_printing(int level)
> {
> - return (level >= console_loglevel && !ignore_loglevel);
> + if (unlikely(mute_console))
> + return true;
> +
> + if (unlikely(ignore_loglevel))
> + return false;
> +
> + return (level >= console_loglevel);
> }
This is one way of doing it. Another one is to clear CON_ENABLED bit
from all consoles (upon registration), one upside of this is that we
will signal user-space that consoles are disabled/muted (by removing
the E flag from /proc/consoles).
But, if I'm mistaken, but this mutes only printk side, consoles still
have uart running:
printf -> tty -> uart -> serial_driver_IRQ() -> TX
seriaal_driver_IRQ() -> RX -> uart -> tty
so user space, in theory, still can push messages to slow consoles,
AFAIU.
Thinking more about it. We are still relying on the fact that there is
anything registered as console driver, which is not necessarily the case,
we can have NULL console drivers list. So how about having a dummy struct
console in printk, with NOP read/write and NOP tty_driver and NOP
tty_operations. So that when init calls filp_open("/dev/console") and
we can't give tty anything but NULL, we'd just give tty back the dummy
NOP device.
-ss
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-23 0:33 ` Sergey Senozhatsky
@ 2020-10-23 12:11 ` Petr Mladek
0 siblings, 0 replies; 15+ messages in thread
From: Petr Mladek @ 2020-10-23 12:11 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Steven Rostedt, John Ogness, Linus Torvalds, Guenter Roeck,
Shreyas Joshi, shreyasjoshi15, Greg Kroah-Hartman,
Sergey Senozhatsky, linux-kernel
On Fri 2020-10-23 09:33:34, Sergey Senozhatsky wrote:
> On (20/10/22 13:42), Petr Mladek wrote:
> > +static bool mute_console;
> > +
> > +static int __init mute_console_setup(char *str)
> > +{
> > + mute_console = true;
> > + pr_info("All consoles muted.\n");
> > +
> > + return 0;
> > +}
>
> First of all, thanks a lot for picking this up and for the patch set!
>
> I've several thoughts and comments below.
>
> > static bool suppress_message_printing(int level)
> > {
> > - return (level >= console_loglevel && !ignore_loglevel);
> > + if (unlikely(mute_console))
> > + return true;
> > +
> > + if (unlikely(ignore_loglevel))
> > + return false;
> > +
> > + return (level >= console_loglevel);
> > }
>
> This is one way of doing it. Another one is to clear CON_ENABLED bit
> from all consoles (upon registration), one upside of this is that we
> will signal user-space that consoles are disabled/muted (by removing
> the E flag from /proc/consoles).
Hmm, CON_ENABLED is used by suspend/resume code unconditionaly. We
would need another flag to define the state after resume.
Well, it is true that CON_ENABLED has the same effect. Messages are
not printed to the console. So, introducing another variable is
likely overkill.
> Thinking more about it. We are still relying on the fact that there is
> anything registered as console driver, which is not necessarily the case,
> we can have NULL console drivers list. So how about having a dummy struct
> console in printk, with NOP read/write and NOP tty_driver and NOP
> tty_operations. So that when init calls filp_open("/dev/console") and
> we can't give tty anything but NULL, we'd just give tty back the dummy
> NOP device.
Yup, this seems to be the best solution.
Best Regards,
Petr
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC 1/2] printk: Add kernel parameter: mute_console
2020-10-22 11:42 ` [RFC 1/2] printk: Add kernel parameter: mute_console Petr Mladek
` (2 preceding siblings ...)
2020-10-23 0:33 ` Sergey Senozhatsky
@ 2020-10-23 15:59 ` Linus Torvalds
3 siblings, 0 replies; 15+ messages in thread
From: Linus Torvalds @ 2020-10-23 15:59 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Steven Rostedt, John Ogness, Guenter Roeck,
Shreyas Joshi, shreyasjoshi15, Greg Kroah-Hartman,
Sergey Senozhatsky, Linux Kernel Mailing List
On Thu, Oct 22, 2020 at 4:42 AM Petr Mladek <pmladek@suse.com> wrote:
>
> Users use various undocumented ways how to completely disable
> console output. It is usually done by passing an invalid console
> name, for example, console="", console=null.
>
> It mostly works but just by chance.
Honestly, since that 'console=""' seems to be out in the wild, I think
we might as well just (a) document it, and (b) make sure it works by
more than chance.
That said, I also like John Ogness' suggestion to have it as a
per-console option to mute a particular console. At least that seems
like a perfectly fine extension.
I don't really see the point of a whole new "mute_console" option,
considering that people already figured out an alternate way to do it
that we'd have to support going forward anyway. Just make that the
standard.
Linus
^ permalink raw reply [flat|nested] 15+ messages in thread