[PATCH 0/2] printk/console: Use ttynull when no console is available or wanted

[PATCH 0/2] printk/console: Use ttynull when no console is available or wanted

[Petr Mladek]

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/20201006025935.GA597@jagdpanzerIV.localdomain

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

 drivers/tty/Kconfig     | 14 --------------
 drivers/tty/Makefile    |  3 +--
 drivers/tty/ttynull.c   | 18 ++++++++++++++++++
 include/linux/console.h |  3 +++
 init/main.c             | 10 ++++++++--
 kernel/printk/printk.c  |  9 ++++++++-
 6 files changed, 38 insertions(+), 19 deletions(-)

-- 
2.26.2

[PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[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 <pmladek@suse.com>
---
 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(-)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 93fd984eb2f5..ca359bbd62f5 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -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
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 020b1cd9294f..f6b6bee0422d 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -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
diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
index 17f05b7eb6d3..eced70ec54e1 100644
--- a/drivers/tty/ttynull.c
+++ b/drivers/tty/ttynull.c
@@ -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;
diff --git a/include/linux/console.h b/include/linux/console.h
index 4b1e26c4cb42..9c662e41cde5 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -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;
 
diff --git a/init/main.c b/init/main.c
index 130376ec10ba..24413c055a85 100644
--- a/init/main.c
+++ b/init/main.c
@@ -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);
-- 
2.26.2

Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[Greg Kroah-Hartman]

On Wed, Nov 11, 2020 at 02:54:49PM +0100, Petr Mladek wrote:
> 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 <pmladek@suse.com>

Tricky, and nice to use the existing driver for this, I like it:

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[Guenter Roeck]

On Wed, Nov 11, 2020 at 02:54:49PM +0100, Petr Mladek wrote:
> 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 <pmladek@suse.com>

Reviewed-and-tested-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  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(-)
> 
> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index 93fd984eb2f5..ca359bbd62f5 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -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
> diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
> index 020b1cd9294f..f6b6bee0422d 100644
> --- a/drivers/tty/Makefile
> +++ b/drivers/tty/Makefile
> @@ -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
> diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> index 17f05b7eb6d3..eced70ec54e1 100644
> --- a/drivers/tty/ttynull.c
> +++ b/drivers/tty/ttynull.c
> @@ -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;
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 4b1e26c4cb42..9c662e41cde5 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -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;
>  
> diff --git a/init/main.c b/init/main.c
> index 130376ec10ba..24413c055a85 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -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);
> -- 
> 2.26.2
> 

Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[Sergey Senozhatsky]

On (20/11/11 14:54), Petr Mladek wrote:
> 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 <pmladek@suse.com>

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

	-ss

Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[Sergey Senozhatsky]

On (20/11/11 14:54), Petr Mladek wrote:
[..]
> diff --git a/init/main.c b/init/main.c
> index 130376ec10ba..24413c055a85 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -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")

- filp_open() failure does not necessarily mean that we have console=
  and hence must register null-tty driver

- this will keep low level printk/tty details within the printk

Something like this?

---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 08c50d8ba110..202fa87eb991 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2633,6 +2633,12 @@ struct tty_driver *console_device(int *index)
 	struct tty_driver *driver = NULL;
 
 	console_lock();
+	if (unlikely(!console_drivers)) {
+		console_unlock();
+		register_ttynull_console();
+		console_lock();
+	}
+
 	for_each_console(c) {
 		if (!c->device)
 			continue;

Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[Sergey Senozhatsky]

On (20/11/12 09:17), Sergey Senozhatsky wrote:
> On (20/11/11 14:54), Petr Mladek wrote:
> [..]
> > diff --git a/init/main.c b/init/main.c
> > index 130376ec10ba..24413c055a85 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -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")

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

Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console

[Petr Mladek]

On Thu 2020-11-12 10:45:46, Sergey Senozhatsky wrote:
> On (20/11/12 09:17), Sergey Senozhatsky wrote:
> > On (20/11/11 14:54), Petr Mladek wrote:
> > [..]
> > > diff --git a/init/main.c b/init/main.c
> > > index 130376ec10ba..24413c055a85 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -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")

Good point!

My concern is that console_device might be called in "unclear"
context. For example, it is called under tty_mutex in:

	+ tty_open_by_driver()
	  + tty_lookup_driver()
	    + console_device()

Also console_on_rootf() is likely the first code that would actually
use the device.

Well, there is spk_ttyio_initialise_ldisc() that calls tty_kopen().
I am a bit lazy to investigate whether it is called sooner or later.
Anyway, it is accessibility code, so that there should be configured
an accessibility console anyway.

> 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

This looks like an userspace tool, so it should get called after
console_on_rootfs().

It might be my laziness. But I would prefer to go with this patchset.
We could always improve it when anyone meet the problem.

Best Regards,
Petr

ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

+CC Buildroot folks

Hi Petr,

On 11/11/20 5:54 AM, Petr Mladek wrote:
> 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 <pmladek@suse.com>

> --- a/init/main.c
> +++ b/init/main.c
> @@ -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;
> +		}


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

ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

+CC Buildroot folks

Hi Petr,

On 11/11/20 5:54 AM, Petr Mladek wrote:
> 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 <pmladek@suse.com>

> --- a/init/main.c
> +++ b/init/main.c
> @@ -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;
> +		}


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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

+CC Buildroot folks

Hi Petr,

On 11/11/20 5:54 AM, Petr Mladek wrote:
> 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 <pmladek@suse.com>

> --- a/init/main.c
> +++ b/init/main.c
> @@ -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;
> +		}


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

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[John Ogness]

Hi Vineet,

On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> 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.

John Ogness

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[John Ogness]

Hi Vineet,

On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> 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.

John Ogness

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Greg Ungerer]

Hi John,

On 7/1/21 7:02 pm, John Ogness wrote:
> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>> 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.

I can show an example for m68knommu which this change breaks too
(with no console output on boot).

All the ColdFire dev board targets (arch/m68k/configs/m5*) have a 
compiled in boot argument which is "root=/dev/mtdblock0". They have no
real mechanism to pass boot arguments from their boot loader, so it is
compiled in.

The default mcf serial driver is the console on these and no 
"console=ttyS0" argument was required in the past.

Regards
Greg

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Greg Ungerer]

Hi John,

On 7/1/21 7:02 pm, John Ogness wrote:
> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>> 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.

I can show an example for m68knommu which this change breaks too
(with no console output on boot).

All the ColdFire dev board targets (arch/m68k/configs/m5*) have a 
compiled in boot argument which is "root=/dev/mtdblock0". They have no
real mechanism to pass boot arguments from their boot loader, so it is
compiled in.

The default mcf serial driver is the console on these and no 
"console=ttyS0" argument was required in the past.

Regards
Greg



_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

Hi John,

On 1/7/21 1:02 AM, John Ogness wrote:
> Hi Vineet,
> 
> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>> 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

And we do have serial driver built-in.

Thx,
-Vineet

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

Hi John,

On 1/7/21 1:02 AM, John Ogness wrote:
> Hi Vineet,
> 
> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>> 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

And we do have serial driver built-in.

Thx,
-Vineet

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

Hi John,

On 1/7/21 1:02 AM, John Ogness wrote:
> Hi Vineet,
> 
> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>> 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

And we do have serial driver built-in.

Thx,
-Vineet

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek]

On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> Hi John,
> 
> On 1/7/21 1:02 AM, John Ogness wrote:
> > Hi Vineet,
> > 
> > On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> > > 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

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@suse.com/
This mystery is a good reason to avoid bigger changes at this stage.

Best Regards,
Petr

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek]

On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> Hi John,
> 
> On 1/7/21 1:02 AM, John Ogness wrote:
> > Hi Vineet,
> > 
> > On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> > > 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

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@suse.com/
This mystery is a good reason to avoid bigger changes at this stage.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

On 1/7/21 9:04 AM, Petr Mladek wrote:
> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
>> Hi John,
>>
>> On 1/7/21 1:02 AM, John Ogness wrote:
>>> Hi Vineet,
>>>
>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>>>> 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
> 
> 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.

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

I don't know if ttyS0 console should have registered already but even if 
it did - the /dev node missing would not have helped ?

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

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

On 1/7/21 9:04 AM, Petr Mladek wrote:
> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
>> Hi John,
>>
>> On 1/7/21 1:02 AM, John Ogness wrote:
>>> Hi Vineet,
>>>
>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>>>> 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
> 
> 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.

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

I don't know if ttyS0 console should have registered already but even if 
it did - the /dev node missing would not have helped ?

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


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

On 1/7/21 9:04 AM, Petr Mladek wrote:
> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
>> Hi John,
>>
>> On 1/7/21 1:02 AM, John Ogness wrote:
>>> Hi Vineet,
>>>
>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>>>> 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
> 
> 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.

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

I don't know if ttyS0 console should have registered already but even if 
it did - the /dev node missing would not have helped ?

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

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Sergey Senozhatsky]

On (21/01/07 09:58), Vineet Gupta wrote:
> On 1/7/21 9:04 AM, Petr Mladek wrote:
> > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> > > Hi John,
> > > 
> > > On 1/7/21 1:02 AM, John Ogness wrote:
> > > > Hi Vineet,
> > > > 
> > > > On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> > > > > 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
> > 
> > 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.

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@jagdpanzerIV.localdomain/

	-ss

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Sergey Senozhatsky]

On (21/01/07 09:58), Vineet Gupta wrote:
> On 1/7/21 9:04 AM, Petr Mladek wrote:
> > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> > > Hi John,
> > > 
> > > On 1/7/21 1:02 AM, John Ogness wrote:
> > > > Hi Vineet,
> > > > 
> > > > On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> > > > > 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
> > 
> > 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.

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@jagdpanzerIV.localdomain/

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:
> On (21/01/07 09:58), Vineet Gupta wrote:
>> On 1/7/21 9:04 AM, Petr Mladek wrote:
>>> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
>>>> Hi John,
>>>>
>>>> On 1/7/21 1:02 AM, John Ogness wrote:
>>>>> Hi Vineet,
>>>>>
>>>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>>>>>> 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
>>>
>>> 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.
> 
> 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@jagdpanzerIV.localdomain/

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.


| Warning: unable to open an initial console. Fallback to ttynull.
| Warning: Failed to add ttynull console. No stdin, stdout, and stderr 
for the init process!
| Freeing unused kernel memory: 3096K
| This architecture does not have kernel memory protection.
| Run /init as init process
| with arguments:
|    /init
|  with environment:
|    HOME=/
|    TERM=linux
| Starting System logger (syslogd)
| Bringing up loopback device
| Starting inetd
| Mounting Posix Mqueue filesys
| 
CONFIG_INITRAMFS_SOURCE="~/arc/RAMFS/archs/ramfs_2011-GNU-2020-03-glibc-2.32-tiny"
| **********************************************************************
|			Welcome to ARCLinux
| **********************************************************************
| [ARCLinux]#

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:
> On (21/01/07 09:58), Vineet Gupta wrote:
>> On 1/7/21 9:04 AM, Petr Mladek wrote:
>>> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
>>>> Hi John,
>>>>
>>>> On 1/7/21 1:02 AM, John Ogness wrote:
>>>>> Hi Vineet,
>>>>>
>>>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>>>>>> 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
>>>
>>> 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.
> 
> 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@jagdpanzerIV.localdomain/

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.


| Warning: unable to open an initial console. Fallback to ttynull.
| Warning: Failed to add ttynull console. No stdin, stdout, and stderr 
for the init process!
| Freeing unused kernel memory: 3096K
| This architecture does not have kernel memory protection.
| Run /init as init process
| with arguments:
|    /init
|  with environment:
|    HOME=/
|    TERM=linux
| Starting System logger (syslogd)
| Bringing up loopback device
| Starting inetd
| Mounting Posix Mqueue filesys
| 
CONFIG_INITRAMFS_SOURCE="~/arc/RAMFS/archs/ramfs_2011-GNU-2020-03-glibc-2.32-tiny"
| **********************************************************************
|			Welcome to ARCLinux
| **********************************************************************
| [ARCLinux]#

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Vineet Gupta]

On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:
> On (21/01/07 09:58), Vineet Gupta wrote:
>> On 1/7/21 9:04 AM, Petr Mladek wrote:
>>> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
>>>> Hi John,
>>>>
>>>> On 1/7/21 1:02 AM, John Ogness wrote:
>>>>> Hi Vineet,
>>>>>
>>>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
>>>>>> 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
>>>
>>> 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.
> 
> 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/

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.


| Warning: unable to open an initial console. Fallback to ttynull.
| Warning: Failed to add ttynull console. No stdin, stdout, and stderr 
for the init process!
| Freeing unused kernel memory: 3096K
| This architecture does not have kernel memory protection.
| Run /init as init process
| with arguments:
|    /init
|  with environment:
|    HOME=/
|    TERM=linux
| Starting System logger (syslogd)
| Bringing up loopback device
| Starting inetd
| Mounting Posix Mqueue filesys
| 
CONFIG_INITRAMFS_SOURCE="~/arc/RAMFS/archs/ramfs_2011-GNU-2020-03-glibc-2.32-tiny"
| **********************************************************************
|			Welcome to ARCLinux
| **********************************************************************
| [ARCLinux]#

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek]

On Thu 2021-01-07 21:18:20, Vineet Gupta wrote:
> On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:
> > On (21/01/07 09:58), Vineet Gupta wrote:
> > > On 1/7/21 9:04 AM, Petr Mladek wrote:
> > > > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> > > > > Hi John,
> > > > > 
> > > > > On 1/7/21 1:02 AM, John Ogness wrote:
> > > > > > Hi Vineet,
> > > > > > 
> > > > > > On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> > > > > > > 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
> > > > 
> > > > 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.

I see. I did not though about a possibility that /dev/console could
not be opened from other reasons.

> > 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@jagdpanzerIV.localdomain/
> 
> 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.

IMHO, this worked because you removed the change in console_on_rootfs().

I guess that the change in console_device() did not make any
difference. It was likely not called because
filp_open("/dev/console", O_RDWR, 0) failed earlier because
/dev/ did not exists.

Anyway, the proposed change in console_device() has some
more problems that I realized this week:

   + It does not check whether console_drivers really contains
     any console with tty binding.

   + register_ttynull_console() calls
    add_preferred_console(ttynull_console.name, 0, NULL).
    The ttynull console stays preferred even when any better
    console gets registered later. As a result, it would
    stay associated with /dev/console.

The right solution would be to enable ttynull console and
do _not_ modify the list of preferred consoles. And it makes
sense to add the console only there is no console with
tty binding at the moment.

I still have to think whether console_device() is a better or
worse location for adding tyynull as a fallback.

Anyway, it has to wait. The proper solution can't be done easily
with the existing register_console() code. We need to clean
it up first.

Best Regards,
Petr

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek]

On Thu 2021-01-07 21:18:20, Vineet Gupta wrote:
> On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:
> > On (21/01/07 09:58), Vineet Gupta wrote:
> > > On 1/7/21 9:04 AM, Petr Mladek wrote:
> > > > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> > > > > Hi John,
> > > > > 
> > > > > On 1/7/21 1:02 AM, John Ogness wrote:
> > > > > > Hi Vineet,
> > > > > > 
> > > > > > On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
> > > > > > > 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
> > > > 
> > > > 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.

I see. I did not though about a possibility that /dev/console could
not be opened from other reasons.

> > 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@jagdpanzerIV.localdomain/
> 
> 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.

IMHO, this worked because you removed the change in console_on_rootfs().

I guess that the change in console_device() did not make any
difference. It was likely not called because
filp_open("/dev/console", O_RDWR, 0) failed earlier because
/dev/ did not exists.

Anyway, the proposed change in console_device() has some
more problems that I realized this week:

   + It does not check whether console_drivers really contains
     any console with tty binding.

   + register_ttynull_console() calls
    add_preferred_console(ttynull_console.name, 0, NULL).
    The ttynull console stays preferred even when any better
    console gets registered later. As a result, it would
    stay associated with /dev/console.

The right solution would be to enable ttynull console and
do _not_ modify the list of preferred consoles. And it makes
sense to add the console only there is no console with
tty binding at the moment.

I still have to think whether console_device() is a better or
worse location for adding tyynull as a fallback.

Anyway, it has to wait. The proper solution can't be done easily
with the existing register_console() code. We need to clean
it up first.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Peter Korsgaard]

>>>>> "Vineet" == Vineet Gupta <vgupta@synopsys.com> writes:

 > On 1/7/21 9:04 AM, Petr Mladek wrote:
 >> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
 >>> Hi John,
 >>> 
 >>> On 1/7/21 1:02 AM, John Ogness wrote:
 >>>> Hi Vineet,
 >>>> 
 >>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
 >>>>> 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
 >> 
 >> 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.

But our initramfs/cpio logic ensures that the initramfs has a static
/dev/console device node, so how can that be?

https://git.buildroot.net/buildroot/tree/fs/cpio/cpio.mk#n25

-- 
Bye, Peter Korsgaard

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Peter Korsgaard]

>>>>> "Vineet" == Vineet Gupta <vgupta@synopsys.com> writes:

 > On 1/7/21 9:04 AM, Petr Mladek wrote:
 >> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
 >>> Hi John,
 >>> 
 >>> On 1/7/21 1:02 AM, John Ogness wrote:
 >>>> Hi Vineet,
 >>>> 
 >>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
 >>>>> 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
 >> 
 >> 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.

But our initramfs/cpio logic ensures that the initramfs has a static
/dev/console device node, so how can that be?

https://git.buildroot.net/buildroot/tree/fs/cpio/cpio.mk#n25

-- 
Bye, Peter Korsgaard

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Peter Korsgaard]

>>>>> "Vineet" == Vineet Gupta <vgupta@synopsys.com> writes:

 > On 1/7/21 9:04 AM, Petr Mladek wrote:
 >> On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
 >>> Hi John,
 >>> 
 >>> On 1/7/21 1:02 AM, John Ogness wrote:
 >>>> Hi Vineet,
 >>>> 
 >>>> On 2021-01-06, Vineet Gupta <vgupta@synopsys.com> wrote:
 >>>>> 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
 >> 
 >> 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.

But our initramfs/cpio logic ensures that the initramfs has a static
/dev/console device node, so how can that be?

https://git.buildroot.net/buildroot/tree/fs/cpio/cpio.mk#n25

-- 
Bye, Peter Korsgaard

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Richard Weinberger]

[CC'in linux-um since there is a similar issue]




On Thu, Jan 7, 2021 at 12:38 AM Vineet Gupta <vgupta@synopsys.com> wrote:
>
> +CC Buildroot folks
>
> Hi Petr,
>
> On 11/11/20 5:54 AM, Petr Mladek wrote:
> > 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 <pmladek@suse.com>
>
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -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;
> > +             }
>
>
> 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



--
Thanks,
//richard

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Richard Weinberger]

[CC'in linux-um since there is a similar issue]




On Thu, Jan 7, 2021 at 12:38 AM Vineet Gupta <vgupta@synopsys.com> wrote:
>
> +CC Buildroot folks
>
> Hi Petr,
>
> On 11/11/20 5:54 AM, Petr Mladek wrote:
> > 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 <pmladek@suse.com>
>
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -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;
> > +             }
>
>
> 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



--
Thanks,
//richard

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek]

On Wed 2021-01-06 15:36:36, Vineet Gupta wrote:
> +CC Buildroot folks
> 
> Hi Petr,
> 
> On 11/11/20 5:54 AM, Petr Mladek wrote:
> > 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 <pmladek@suse.com>
> 
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -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;
> > +		}
> 
> 
> This breaks ARC booting (no output on console).

This is likely the same problem as with kunit and um kernels.
It is being discussed at
https://lore.kernel.org/linux-kselftest/X%2FSRA1P8t+ONZFKb@alley/#t

We have several workarounds. I am still squashing my head about the
right solution. The console registration code is like a vasps' nest.
It is always a pain when we touch it.

I hope that I will send a patchset for review later today.
In the worst case, we will revert the patch in the mainline.

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

Good to know.

> 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

Two workarounds can be fount at
https://lore.kernel.org/linux-kselftest/X%2FSYhBZyudfnKY1u@alley/
https://lore.kernel.org/linux-kselftest/X%2FW2sl7RMvfaV4Ru@alley/

But I still see them as only a partial solutiuon. I still another sources
of potential problems.

Best Regards,
Petr

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek]

On Wed 2021-01-06 15:36:36, Vineet Gupta wrote:
> +CC Buildroot folks
> 
> Hi Petr,
> 
> On 11/11/20 5:54 AM, Petr Mladek wrote:
> > 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 <pmladek@suse.com>
> 
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -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;
> > +		}
> 
> 
> This breaks ARC booting (no output on console).

This is likely the same problem as with kunit and um kernels.
It is being discussed at
https://lore.kernel.org/linux-kselftest/X%2FSRA1P8t+ONZFKb@alley/#t

We have several workarounds. I am still squashing my head about the
right solution. The console registration code is like a vasps' nest.
It is always a pain when we touch it.

I hope that I will send a patchset for review later today.
In the worst case, we will revert the patch in the mainline.

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

Good to know.

> 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

Two workarounds can be fount at
https://lore.kernel.org/linux-kselftest/X%2FSYhBZyudfnKY1u@alley/
https://lore.kernel.org/linux-kselftest/X%2FW2sl7RMvfaV4Ru@alley/

But I still see them as only a partial solutiuon. I still another sources
of potential problems.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Yann E. MORIN]

Vineet, All,

On 2021-01-06 15:36 -0800, Vineet Gupta spake thusly:
> On 11/11/20 5:54 AM, Petr Mladek wrote:
[--SNIP--]
> >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 <pmladek@suse.com>
> 
> >--- a/init/main.c
> >+++ b/init/main.c
> >@@ -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;
> >+		}
> 
> 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 "$@"

I guess you are speaking about the initramfs (cpio) case, right?

We've changed that code last August:

    https://git.buildroot.org/buildroot/commit/fs/cpio/init?id=b9026e83f

I.e. if we can't do the redirection, then we don't redirect anything.
The change was done for people who explicitly pass an empty console= on
their kernel command line.

Now, I haven't looked at nulltty yet, and I have (so far) no idea on how
it works. Thanks for the hint, I'll have a look.

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

See also more archaelogy on that topic, referenced in that commit:
    https://git.buildroot.org/buildroot/commit/fs/cpio/?id=98a6f1fc02e41

> Please advise what needs to be done to unbork boot.

This has been present since the 2020.08 release, and has been backported
to the maintenance branches:
    2020.02.x (LTS) -> f1a83afe2df2a
    2020.05.x       -> 797f9e40224c9

> 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

I won't speak about whether this is a kernel regression or not, not my
call.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: [Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Yann E. MORIN]

Vineet, All,

On 2021-01-06 15:36 -0800, Vineet Gupta spake thusly:
> On 11/11/20 5:54 AM, Petr Mladek wrote:
[--SNIP--]
> >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 <pmladek@suse.com>
> 
> >--- a/init/main.c
> >+++ b/init/main.c
> >@@ -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;
> >+		}
> 
> 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 "$@"

I guess you are speaking about the initramfs (cpio) case, right?

We've changed that code last August:

    https://git.buildroot.org/buildroot/commit/fs/cpio/init?id=b9026e83f

I.e. if we can't do the redirection, then we don't redirect anything.
The change was done for people who explicitly pass an empty console= on
their kernel command line.

Now, I haven't looked at nulltty yet, and I have (so far) no idea on how
it works. Thanks for the hint, I'll have a look.

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

See also more archaelogy on that topic, referenced in that commit:
    https://git.buildroot.org/buildroot/commit/fs/cpio/?id=98a6f1fc02e41

> Please advise what needs to be done to unbork boot.

This has been present since the 2020.08 release, and has been backported
to the maintenance branches:
    2020.02.x (LTS) -> f1a83afe2df2a
    2020.05.x       -> 797f9e40224c9

> 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

I won't speak about whether this is a kernel regression or not, not my
call.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[Buildroot] ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Yann E. MORIN]

Vineet, All,

On 2021-01-06 15:36 -0800, Vineet Gupta spake thusly:
> On 11/11/20 5:54 AM, Petr Mladek wrote:
[--SNIP--]
> >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 <pmladek@suse.com>
> 
> >--- a/init/main.c
> >+++ b/init/main.c
> >@@ -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;
> >+		}
> 
> 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 "$@"

I guess you are speaking about the initramfs (cpio) case, right?

We've changed that code last August:

    https://git.buildroot.org/buildroot/commit/fs/cpio/init?id=b9026e83f

I.e. if we can't do the redirection, then we don't redirect anything.
The change was done for people who explicitly pass an empty console= on
their kernel command line.

Now, I haven't looked at nulltty yet, and I have (so far) no idea on how
it works. Thanks for the hint, I'll have a look.

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

See also more archaelogy on that topic, referenced in that commit:
    https://git.buildroot.org/buildroot/commit/fs/cpio/?id=98a6f1fc02e41

> Please advise what needs to be done to unbork boot.

This has been present since the 2020.08 release, and has been backported
to the maintenance branches:
    2020.02.x (LTS) -> f1a83afe2df2a
    2020.05.x       -> 797f9e40224c9

> 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

I won't speak about whether this is a kernel regression or not, not my
call.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[PATCH 2/2] printk/console: Allow to disable console output by using console="" or console=null

[Petr Mladek]

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/20201006025935.GA597@jagdpanzerIV.localdomain
Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 kernel/printk/printk.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fe64a49344bf..ac440b879a2c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -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;
-- 
2.26.2

Re: [PATCH 2/2] printk/console: Allow to disable console output by using console="" or console=null

[Guenter Roeck]

On Wed, Nov 11, 2020 at 02:54:50PM +0100, Petr Mladek wrote:
> 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/20201006025935.GA597@jagdpanzerIV.localdomain
> Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Signed-off-by: Petr Mladek <pmladek@suse.com>

Reviewed-and-tested-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  kernel/printk/printk.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index fe64a49344bf..ac440b879a2c 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -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;
> -- 
> 2.26.2
> 

Re: [PATCH 2/2] printk/console: Allow to disable console output by using console="" or console=null

[Sergey Senozhatsky]

On (20/11/11 14:54), Petr Mladek wrote:
> 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/20201006025935.GA597@jagdpanzerIV.localdomain
> Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Signed-off-by: Petr Mladek <pmladek@suse.com>

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

	-ss

Re: [PATCH 0/2] printk/console: Use ttynull when no console is available or wanted

[Petr Mladek]

On Wed 2020-11-11 14:54:48, Petr Mladek wrote:
> 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/20201006025935.GA597@jagdpanzerIV.localdomain
> 
> 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

The patchset has been committed into printk/linux.git, branch
for-5.11-null-console.

Best Regards,
Petr