printk/console: Use ttynull when no console is available or wanted

stdin, stdout, and stderr standard I/O stream are created for the init process. They are not available when there is no console registered for /dev/console. It might lead to a crash when the init process tries to use them, see the commit 48021f98130880dd742 ("printk: handle blank console arguments passed in.").

Normally, ttySX and ttyX consoles are used as a fallback when no consoles are defined via the command line, device tree, or SPCR. But there will be no console registered when an invalid console name is configured or when the configured consoles do not exist on the system.

Users even try to avoid the console intentionally, for example, by using console="" or console=null. It is used on production systems where the serial port or terminal are not visible to users. Pushing messages to these consoles would just unnecessary slowdown the system.

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

stdin, stdout, and stderr standard I/O stream are created for the init process. They are not available when there is no console registered for /dev/console. It might lead to a crash when the init process tries to use them, see the commit 48021f98130880dd742 ("printk: handle blank console arguments passed in.").

Normally, ttySX and ttyX consoles are used as a fallback when no consoles are defined via the command line, device tree, or SPCR. But there will be no console registered when an invalid console name is configured or when the configured consoles do not exist on the system.

Users even try to avoid the console intentionally, for example, by using console="" or console=null. It is used on production systems where the serial port or terminal are not visible to users. Pushing messages to these consoles would just unnecessary slowdown the system.

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

---
 drivers/tty/Kconfig     | 14 --------------
 drivers/tty/Makefile    |  3 +--
 drivers/tty/ttynull.c   | 18 ++++++++++++++++++
 include/linux/console.h |  3 +++
 init/main.c             | 10 ++++++++--
 5 files changed, 30 insertions(+), 18 deletions(-)

drivers/tty/Kconfig +0 -14

index 93fd984eb2f5..ca359bbd62f5 100644
@@ -428,20 +428,6 @@ config MIPS_EJTAG_FDC_KGDB_CHAN
 	help
 	  FDC channel number to use for KGDB.
 
-config NULL_TTY
-	tristate "NULL TTY driver"
-	help
-	  Say Y here if you want a NULL TTY which simply discards messages.
-
-	  This is useful to allow userspace applications which expect a console
-	  device to work without modifications even when no console is
-	  available or desired.
-
-	  In order to use this driver, you should redirect the console to this
-	  TTY, or boot the kernel with console=ttynull.
-
-	  If unsure, say N.
-
 config TRACE_ROUTER
 	tristate "Trace data router for MIPI P1149.7 cJTAG standard"
 	depends on TRACE_SINK

drivers/tty/Makefile +1 -2

index 020b1cd9294f..f6b6bee0422d 100644
@@ -2,7 +2,7 @@
 obj-$(CONFIG_TTY)		+= tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o \
 				   tty_buffer.o tty_port.o tty_mutex.o \
 				   tty_ldsem.o tty_baudrate.o tty_jobctrl.o \
-				   n_null.o
+				   n_null.o ttynull.o
 obj-$(CONFIG_LEGACY_PTYS)	+= pty.o
 obj-$(CONFIG_UNIX98_PTYS)	+= pty.o
 obj-$(CONFIG_AUDIT)		+= tty_audit.o

@@ -25,7 +25,6 @@ obj-$(CONFIG_ISI)		+= isicom.o
 obj-$(CONFIG_MOXA_INTELLIO)	+= moxa.o
 obj-$(CONFIG_MOXA_SMARTIO)	+= mxser.o
 obj-$(CONFIG_NOZOMI)		+= nozomi.o
-obj-$(CONFIG_NULL_TTY)	        += ttynull.o
 obj-$(CONFIG_ROCKETPORT)	+= rocket.o
 obj-$(CONFIG_SYNCLINK_GT)	+= synclink_gt.o
 obj-$(CONFIG_SYNCLINKMP)	+= synclinkmp.o

drivers/tty/ttynull.c +18 -0

index 17f05b7eb6d3..eced70ec54e1 100644
@@ -2,6 +2,13 @@
 /*
  * Copyright (C) 2019 Axis Communications AB
  *
+ * The console is useful for userspace applications which expect a console
+ * device to work without modifications even when no console is available
+ * or desired.
+ *
+ * In order to use this driver, you should redirect the console to this
+ * TTY, or boot the kernel with console=ttynull.
+ *
  * Based on ttyprintk.c:
  *  Copyright (C) 2010 Samo Pogacnik
  */

@@ -59,6 +66,17 @@ static struct console ttynull_console = {
 	.device = ttynull_device,
 };
 
+void __init register_ttynull_console(void)
+{
+	if (!ttynull_driver)
+		return;
+
+	if (add_preferred_console(ttynull_console.name, 0, NULL))
+		return;
+
+	register_console(&ttynull_console);
+}
+
 static int __init ttynull_init(void)
 {
 	struct tty_driver *driver;

include/linux/console.h +3 -0

index 4b1e26c4cb42..9c662e41cde5 100644
@@ -187,9 +187,12 @@ extern int braille_register_console(struct console *, int index,
 extern int braille_unregister_console(struct console *);
 #ifdef CONFIG_TTY
 extern void console_sysfs_notify(void);
+extern void register_ttynull_console(void);
 #else
 static inline void console_sysfs_notify(void)
 { }
+static inline void register_ttynull_console(void)
+{ }
 #endif
 extern bool console_suspend_enabled;
 

init/main.c +8 -2

index 130376ec10ba..24413c055a85 100644
@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
 	struct file *file = filp_open("/dev/console", O_RDWR, 0);
 
 	if (IS_ERR(file)) {
-		pr_err("Warning: unable to open an initial console.\n");
-		return;
+		pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
+		register_ttynull_console();
+
+		file = filp_open("/dev/console", O_RDWR, 0);
+		if (IS_ERR(file)) {
+			pr_err("Warning: Failed to add ttynull console. No stdin, stdout, and stderr for the init process!\n");
+			return;
+		}
 	}
 	init_dup(file);
 	init_dup(file);

Signature · 1 line

2.26.2

stdin, stdout, and stderr standard I/O stream are created for the init process. They are not available when there is no console registered for /dev/console. It might lead to a crash when the init process tries to use them, see the commit 48021f98130880dd742 ("printk: handle blank console arguments passed in.").

Normally, ttySX and ttyX consoles are used as a fallback when no consoles are defined via the command line, device tree, or SPCR. But there will be no console registered when an invalid console name is configured or when the configured consoles do not exist on the system.

Users even try to avoid the console intentionally, for example, by using console="" or console=null. It is used on production systems where the serial port or terminal are not visible to users. Pushing messages to these consoles would just unnecessary slowdown the system.

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

On (20/11/11 14:54), Petr Mladek wrote:
[..]

init/main.c void __init console_on_rootfs(void) · line 1475

Quoted 13 lines

init/main.c +3 -2

index 130376ec10ba..24413c055a85 100644
@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
 	struct file *file = filp_open("/dev/console", O_RDWR, 0);
 
 	if (IS_ERR(file)) {
-		pr_err("Warning: unable to open an initial console.\n");
-		return;
+		pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
+		register_ttynull_console();
+

A nit, this probably can be done in console_device() function.

For several reasons:

- we will get covered all the future cases when something other than console_on_rootfs() will filp_open("/dev/console")

Quoted 18 lines · Sergey Senozhatsky

On (20/11/11 14:54), Petr Mladek wrote:
[..]

init/main.c void __init console_on_rootfs(void) · line 1475

Quoted 13 lines

init/main.c +3 -2

index 130376ec10ba..24413c055a85 100644
@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
 	struct file *file = filp_open("/dev/console", O_RDWR, 0);
 
 	if (IS_ERR(file)) {
-		pr_err("Warning: unable to open an initial console.\n");
-		return;
+		pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
+		register_ttynull_console();
+

A nit, this probably can be done in console_device() function.

Quoted 4 lines

For several reasons:

- we will get covered all the future cases when something other than console_on_rootfs() will filp_open("/dev/console")

And the existing ones (including user-space). For instance, kernel/bpf/preload/iterators/iterators.c probably fails (?) on systems with console=

	debug_fd = open("/dev/console", O_WRONLY | O_NOCTTY | O_CLOEXEC);
	if (debug_fd < 0)
		return 1;

	-ss

stdin, stdout, and stderr standard I/O stream are created for the init process. They are not available when there is no console registered for /dev/console. It might lead to a crash when the init process tries to use them, see the commit 48021f98130880dd742 ("printk: handle blank console arguments passed in.").

Normally, ttySX and ttyX consoles are used as a fallback when no consoles are defined via the command line, device tree, or SPCR. But there will be no console registered when an invalid console name is configured or when the configured consoles do not exist on the system.

Users even try to avoid the console intentionally, for example, by using console="" or console=null. It is used on production systems where the serial port or terminal are not visible to users. Pushing messages to these consoles would just unnecessary slowdown the system.

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

init/main.c +0 -0

@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
  	struct file *file = filp_open("/dev/console", O_RDWR, 0);
 
  	if (IS_ERR(file)) {

This breaks ARC booting (no output on console).

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Hi John,

Quoted 10 lines · John Ogness

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1

Quoted 15 lines · Vineet Gupta

Hi John,

Quoted 10 lines · John Ogness

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Quoted 2 lines

Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1

This is strange, the problematic patch should use ttynull only as a fallback. It should not be used when a particular console is defined on the command line.

The only explanation would be that ttyS0 gets registered too late and ttynull is added as a fallback in the meantime.

Anyway, I propose the revert the problematic patch for 5.11-rc3, see
https://lore.kernel.org/lkml/20210107164400.17904-2-pmladek at suse.com/ This mystery is a good reason to avoid bigger changes at this stage.

Best Regards,
Petr

Quoted 19 lines · Petr Mladek

Quoted 17 lines · Vineet Gupta

Hi John,

Quoted 10 lines · John Ogness

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1

Quoted 3 lines

This is strange, the problematic patch should use ttynull only as a fallback. It should not be used when a particular console is defined on the command line.

What happens in my case is console_on_rootfs() doesn't find /dev/console and switching to ttynull. /dev is not present because devtmpfs doesn't automount for initramfs.

Quoted 24 lines · Vineet Gupta

Quoted 22 lines · Petr Mladek

Quoted 15 lines · Vineet Gupta

Hi John,

Quoted 10 lines · John Ogness

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Quoted 2 lines

Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1

This is strange, the problematic patch should use ttynull only as a fallback. It should not be used when a particular console is defined on the command line.

Quoted 3 lines

What happens in my case is console_on_rootfs() doesn't find /dev/console and switching to ttynull. /dev is not present because devtmpfs doesn't automount for initramfs.

I wonder if we'll move the nulltty fallback logic into printk code [1] will it fix the problem?

[1] https://lore.kernel.org/lkml/X6x%2FAxD1qanC6evJ at jagdpanzerIV.localdomain/

Quoted 21 lines · Sergey Senozhatsky

Quoted 20 lines · Vineet Gupta

Quoted 19 lines · Petr Mladek

Quoted 17 lines · Vineet Gupta

Hi John,

Quoted 10 lines · John Ogness

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

This is strange, the problematic patch should use ttynull only as a fallback. It should not be used when a particular console is defined on the command line.

What happens in my case is console_on_rootfs() doesn't find /dev/console and switching to ttynull. /dev is not present because devtmpfs doesn't automount for initramfs.

Quoted 4 lines

I wonder if we'll move the nulltty fallback logic into printk code [1] will it fix the problem?

[1] https://lore.kernel.org/lkml/X6x%[email protected]/

Your reasoning in the post above makes total sense.

I tired the patch: adding register_ttynull_console() call in console_device(), removing from console_on_rootfs() band that works too.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Vineet" == Vineet Gupta <[email protected]> writes:

Quoted 19 lines · Petr Mladek

Quoted 17 lines · Vineet Gupta

Hi John,

Quoted 10 lines · John Ogness

Hi Vineet,

Quoted 1 line · Vineet Gupta

This breaks ARC booting (no output on console).

Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now.

Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1

Quoted 3 lines

This is strange, the problematic patch should use ttynull only as a fallback. It should not be used when a particular console is defined on the command line.

What happens in my case is console_on_rootfs() doesn't find /dev/console and switching to ttynull. /dev is not present because devtmpfs doesn't automount for initramfs.

+CC Buildroot folks

Hi Petr,

Quoted 30 lines · Petr Mladek

stdin, stdout, and stderr standard I/O stream are created for the init process. They are not available when there is no console registered for /dev/console. It might lead to a crash when the init process tries to use them, see the commit 48021f98130880dd742 ("printk: handle blank console arguments passed in.").

Normally, ttySX and ttyX consoles are used as a fallback when no consoles are defined via the command line, device tree, or SPCR. But there will be no console registered when an invalid console name is configured or when the configured consoles do not exist on the system.

Users even try to avoid the console intentionally, for example, by using console="" or console=null. It is used on production systems where the serial port or terminal are not visible to users. Pushing messages to these consoles would just unnecessary slowdown the system.

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

init/main.c +0 -0

@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
      struct file *file = filp_open("/dev/console", O_RDWR, 0);
 
      if (IS_ERR(file)) {

init/main.c void __init console_on_rootfs(void) · line 1480

Quoted 10 lines

init/main.c +8 -2

-             pr_err("Warning: unable to open an initial console.\n");
-             return;
+             pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
+             register_ttynull_console();
+
+             file = filp_open("/dev/console", O_RDWR, 0);
+             if (IS_ERR(file)) {
+                     pr_err("Warning: Failed to add ttynull console. No stdin, stdout, and stderr for the init process!\n");
+                     return;
+             }

This breaks ARC booting (no output on console).

Our Buildroot based setup has dynamic /dev where /dev/console doesn't exist statically and there's a primoridla /init shell script which does following

/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init "$@"

Buildroot has had this way of handling missing /dev/console since 2011
[1] and [2].

Please advise what needs to be done to unbork boot. Otherwise this seems like a kernel change which breaks user-space and needs to be backed-out (or perhaps conditionalize on CONFIG_NULL_TTY. I'm surprised it hasn't been reported by any other embedded folks

Thx,
-Vineet

[1] http://lists.busybox.net/pipermail/buildroot/2011-July/044505.html
[2] http://lists.busybox.net/pipermail/buildroot/2011-August/044832.html

+CC Buildroot folks

Hi Petr,

Quoted 34 lines · Petr Mladek

stdin, stdout, and stderr standard I/O stream are created for the init process. They are not available when there is no console registered for /dev/console. It might lead to a crash when the init process tries to use them, see the commit 48021f98130880dd742 ("printk: handle blank console arguments passed in.").

Normally, ttySX and ttyX consoles are used as a fallback when no consoles are defined via the command line, device tree, or SPCR. But there will be no console registered when an invalid console name is configured or when the configured consoles do not exist on the system.

Users even try to avoid the console intentionally, for example, by using console="" or console=null. It is used on production systems where the serial port or terminal are not visible to users. Pushing messages to these consoles would just unnecessary slowdown the system.

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

init/main.c +3 -2

@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
  	struct file *file = filp_open("/dev/console", O_RDWR, 0);
  	if (IS_ERR(file)) {
-		pr_err("Warning: unable to open an initial console.\n");
-		return;
+		pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
+		register_ttynull_console();
+

init/main.c void __init console_on_rootfs(void) · line 1480

Quoted 5 lines

init/main.c +5 -0

+		file = filp_open("/dev/console", O_RDWR, 0);
+		if (IS_ERR(file)) {
+			pr_err("Warning: Failed to add ttynull console. No stdin, stdout, and stderr for the init process!\n");
+			return;
+		}

This breaks ARC booting (no output on console).

Our Buildroot based setup has dynamic /dev where /dev/console doesn't exist statically and there's a primoridla /init shell script which does following

/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init "$@"

Buildroot has had this way of handling missing /dev/console since 2011 [1] and [2].

Please advise what needs to be done to unbork boot. Otherwise this seems like a kernel change which breaks user-space and needs to be backed-out (or perhaps conditionalize on CONFIG_NULL_TTY. I'm surprised it hasn't been reported by any other embedded folks

Quoted 12 lines

Make sure that stdin, stdout, stderr, and /dev/console are always available by a fallback to the existing ttynull driver. It has been implemented for exactly this purpose but it was used only when explicitly configured.

Signed-off-by Petr Mladek <[email protected]>

init/main.c +0 -0

@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
 	struct file *file = filp_open("/dev/console", O_RDWR, 0);
 	if (IS_ERR(file)) {

init/main.c void __init console_on_rootfs(void) · line 1479

Quoted 10 lines

init/main.c +8 -2

-		pr_err("Warning: unable to open an initial console.\n");
-		return;
+		pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
+		register_ttynull_console();
+
+		file = filp_open("/dev/console", O_RDWR, 0);
+		if (IS_ERR(file)) {
+			pr_err("Warning: Failed to add ttynull console. No stdin, stdout, and stderr for the init process!\n");
+			return;
+		}

This breaks ARC booting (no output on console).

Our Buildroot based setup has dynamic /dev where /dev/console doesn't exist statically and there's a primoridla /init shell script which does following

/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init "$@"

Buildroot has had this way of handling missing /dev/console since 2011 [1] and [2].

Please advise what needs to be done to unbork boot.

Otherwise this seems
like a kernel change which breaks user-space and needs to be backed-out (or perhaps conditionalize on CONFIG_NULL_TTY. I'm surprised it hasn't been reported by any other embedded folks

The commit 48021f98130880dd74 ("printk: handle blank console arguments passed in.") prevented crash caused by empty console= parameter value.

Unfortunately, this value is widely used on Chromebooks to disable the console output. The above commit caused performance regression because the messages were pushed on slow console even though nobody was watching it.

Use ttynull driver explicitly for console="" and console=null parameters. It has been created for exactly this purpose.

It causes that preferred_console is set. As a result, ttySX and ttyX are not used as a fallback. And only ttynull console gets registered by default.

It still allows to register other consoles either by additional console= parameters or SPCR. It prevents regression because it worked this way even before. Also it is a sane semantic. Preventing output on all consoles should be done another way, for example, by introducing mute_console parameter.

Link https://lore.kernel.org/r/[email protected] open here

Suggested-by Sergey Senozhatsky <[email protected]>

Signed-off-by Petr Mladek <[email protected]>

The commit 48021f98130880dd74 ("printk: handle blank console arguments passed in.") prevented crash caused by empty console= parameter value.

Unfortunately, this value is widely used on Chromebooks to disable the console output. The above commit caused performance regression because the messages were pushed on slow console even though nobody was watching it.

Use ttynull driver explicitly for console="" and console=null parameters. It has been created for exactly this purpose.

It causes that preferred_console is set. As a result, ttySX and ttyX are not used as a fallback. And only ttynull console gets registered by default.

It still allows to register other consoles either by additional console= parameters or SPCR. It prevents regression because it worked this way even before. Also it is a sane semantic. Preventing output on all consoles should be done another way, for example, by introducing mute_console parameter.

Link https://lore.kernel.org/r/[email protected] open here

Suggested-by Sergey Senozhatsky <[email protected]>

Signed-off-by Petr Mladek <[email protected]>

---
 kernel/printk/printk.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

kernel/printk/printk.c +8 -1

index fe64a49344bf..ac440b879a2c 100644
@@ -2189,8 +2189,15 @@ static int __init console_setup(char *str)
 	char *s, *options, *brl_options = NULL;
 	int idx;
 
-	if (str[0] == 0)
+	/*
+	 * console="" or console=null have been suggested as a way to
+	 * disable console output. Use ttynull that has been created
+	 * for exacly this purpose.
+	 */
+	if (str[0] == 0 || strcmp(str, "null") == 0) {
+		__add_preferred_console("ttynull", 0, NULL, NULL, true);
 		return 1;
+	}
 
 	if (_braille_console_setup(&str, &brl_options))
 		return 1;

Signature · 1 line

2.26.2

This is another attempt to solve regression caused by the commit 48021f98130880dd74 ("printk: handle blank console arguments passed in.").

It prevented a crash caused by empty console= parameter. But it caused performance problems on Chromebooks because they use it to disable all consoles, see
see https://lore.kernel.org/r/[email protected]

Solve both problems by using ttynull console driver that was crated exactly for this purpose.

The 1st patch should prevent the crash for any invalid console name.

The 2nd patch allows to used the ttynull driver also with the widely used console= and console=null parameters.

Best Regards,
Petr

Petr Mladek (2):
init/console: Use ttynull as a fallback when there is no console printk/console: Allow to disable console output by using console="" or
console=null