The commit 757055ae8dedf5333af17b3b ("init/console: Use ttynull as a fallback when
there is no console") caused several regressions. The ttynull console has been
selected by default when no console was configured on the command line and
ttynull_init() was the first initcall calling register_console().
There were few possible workarounds but I was not happy with them.
I worked on a proper solution but it became too complicated to
be used at this stage.
The console registration code is a sad story. There are many hidden catches.
The ordering of registered consoles is not well defined. Any change
in the code tends to break some particular system.
The good news is that I become more and more familiar with it.
I hope that I will be able to clean it up step by step in
the future. But it is definitely not a good idea to do any big
refactoring in rc phase.
Hence I propose to revert the problematic commit as the least
risky solution.
Petr Mladek (1):
Revert "init/console: Use ttynull as a fallback when there is no
console"
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, 18 insertions(+), 30 deletions(-)
--
2.26.2
This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
The commit caused that ttynull was used as the default console
on many systems. It happened when there was no console configured
on the command line and ttynull_init() was the first initcall
calling register_console().
The commit fixed a historical problem that have been there for ages.
The primary motivation was the commit 3cffa06aeef7ece30f6
("printk/console: Allow to disable console output by using console=""
or console=null"). It provided a clean solution
for a workaround that was widely used and worked only by chance.
This revert causes that the console="" or console=null command line
options will again work only by chance. These options will cause that
a particular console will be preferred and the default (tty) ones
will not get enabled. There will be no console registered at
all. As a result there won't be stdin, stdout, and stderr for
the init process. But it worked exactly this way even before.
The proper solution has to fulfill many conditions:
+ Register ttynull only when explicitly required or as
the ultimate fallback.
+ ttynull must get associated with /dev/console but it must
not become preferred console when used as a fallback.
Especially, it must still be possible to replace it
by a better console later.
Such a change requires clean up of the register_console() code.
Otherwise, it would be even harder to follow. Especially, the use
of has_preferred_console and CON_CONSDEV flag is tricky. The clean
up is risky. The ordering of consoles is not well defined. And
any changes tend to break existing user settings.
Do the revert at the least risky solution for now.
Signed-off-by: Petr Mladek <[email protected]>
---
drivers/tty/Kconfig | 14 ++++++++++++++
drivers/tty/Makefile | 3 ++-
drivers/tty/ttynull.c | 18 ------------------
include/linux/console.h | 3 ---
init/main.c | 10 ++--------
5 files changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 47a6e42f0d04..e15cd6b5bb99 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -401,6 +401,20 @@ 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 3c1c5a9240a7..b3ccae932660 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 ttynull.o
+ n_null.o
obj-$(CONFIG_LEGACY_PTYS) += pty.o
obj-$(CONFIG_UNIX98_PTYS) += pty.o
obj-$(CONFIG_AUDIT) += tty_audit.o
@@ -25,6 +25,7 @@ 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_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
index eced70ec54e1..17f05b7eb6d3 100644
--- a/drivers/tty/ttynull.c
+++ b/drivers/tty/ttynull.c
@@ -2,13 +2,6 @@
/*
* 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
*/
@@ -66,17 +59,6 @@ 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 dbe78e8e2602..20874db50bc8 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -186,12 +186,9 @@ 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 421640fca375..c68d784376ca 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1480,14 +1480,8 @@ 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. 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;
- }
+ pr_err("Warning: unable to open an initial console.\n");
+ return;
}
init_dup(file);
init_dup(file);
--
2.26.2
On Thu, Jan 07, 2021 at 05:44:00PM +0100, Petr Mladek wrote:
> This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
>
> The commit caused that ttynull was used as the default console
> on many systems. It happened when there was no console configured
> on the command line and ttynull_init() was the first initcall
> calling register_console().
>
> The commit fixed a historical problem that have been there for ages.
> The primary motivation was the commit 3cffa06aeef7ece30f6
> ("printk/console: Allow to disable console output by using console=""
> or console=null"). It provided a clean solution
> for a workaround that was widely used and worked only by chance.
>
> This revert causes that the console="" or console=null command line
> options will again work only by chance. These options will cause that
> a particular console will be preferred and the default (tty) ones
> will not get enabled. There will be no console registered at
> all. As a result there won't be stdin, stdout, and stderr for
> the init process. But it worked exactly this way even before.
>
> The proper solution has to fulfill many conditions:
>
> + Register ttynull only when explicitly required or as
> the ultimate fallback.
>
> + ttynull must get associated with /dev/console but it must
> not become preferred console when used as a fallback.
> Especially, it must still be possible to replace it
> by a better console later.
>
> Such a change requires clean up of the register_console() code.
> Otherwise, it would be even harder to follow. Especially, the use
> of has_preferred_console and CON_CONSDEV flag is tricky. The clean
> up is risky. The ordering of consoles is not well defined. And
> any changes tend to break existing user settings.
>
> Do the revert at the least risky solution for now.
Shouldn't it have Fixes tag along with Reported-by ones and explanation what
was the actual problem reported?
--
With Best Regards,
Andy Shevchenko
On Thu, Jan 7, 2021 at 9:45 AM Andy Shevchenko
<[email protected]> wrote:
>>
> Shouldn't it have Fixes tag along with Reported-by ones and explanation what
> was the actual problem reported?
No need for a "Fixes" tag for a revert - the commit it reverts _is_
the thing it fixes, so that's implicitly there.
But yes, a reported-by with an explanation of the actual case that
broke would be a very good idea, so that the revert documents the
particular case that caused it, not just the "big picture" case.
Linus
On Thu, Jan 07, 2021 at 05:44:00PM +0100, Petr Mladek wrote:
> This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
>
> The commit caused that ttynull was used as the default console
> on many systems. It happened when there was no console configured
> on the command line and ttynull_init() was the first initcall
> calling register_console().
>
> The commit fixed a historical problem that have been there for ages.
> The primary motivation was the commit 3cffa06aeef7ece30f6
> ("printk/console: Allow to disable console output by using console=""
> or console=null"). It provided a clean solution
> for a workaround that was widely used and worked only by chance.
>
> This revert causes that the console="" or console=null command line
> options will again work only by chance. These options will cause that
> a particular console will be preferred and the default (tty) ones
> will not get enabled. There will be no console registered at
> all. As a result there won't be stdin, stdout, and stderr for
> the init process. But it worked exactly this way even before.
>
> The proper solution has to fulfill many conditions:
>
> + Register ttynull only when explicitly required or as
> the ultimate fallback.
>
> + ttynull must get associated with /dev/console but it must
> not become preferred console when used as a fallback.
> Especially, it must still be possible to replace it
> by a better console later.
>
> Such a change requires clean up of the register_console() code.
> Otherwise, it would be even harder to follow. Especially, the use
> of has_preferred_console and CON_CONSDEV flag is tricky. The clean
> up is risky. The ordering of consoles is not well defined. And
> any changes tend to break existing user settings.
>
> Do the revert at the least risky solution for now.
>
> Signed-off-by: Petr Mladek <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Linus, can you take this directly, or is this going through some other
tree?
thanks,
greg k-h
On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> Linus, can you take this directly, or is this going through some other
> tree?
I was _assuming_ that I'd get it through the normal printk pull
request, it doesn't seem to be that timing-critical.
But if there is nothing else pending, I can certainly take it directly
as that patch too.
Petr?
Linus
On (21/01/07 17:44), Petr Mladek wrote:
>
> This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
>
> The commit caused that ttynull was used as the default console
> on many systems. It happened when there was no console configured
> on the command line and ttynull_init() was the first initcall
> calling register_console().
>
> The commit fixed a historical problem that have been there for ages.
> The primary motivation was the commit 3cffa06aeef7ece30f6
> ("printk/console: Allow to disable console output by using console=""
> or console=null"). It provided a clean solution
> for a workaround that was widely used and worked only by chance.
>
> This revert causes that the console="" or console=null command line
> options will again work only by chance. These options will cause that
> a particular console will be preferred and the default (tty) ones
> will not get enabled. There will be no console registered at
> all. As a result there won't be stdin, stdout, and stderr for
> the init process. But it worked exactly this way even before.
>
> The proper solution has to fulfill many conditions:
>
> + Register ttynull only when explicitly required or as
> the ultimate fallback.
>
> + ttynull must get associated with /dev/console but it must
> not become preferred console when used as a fallback.
> Especially, it must still be possible to replace it
> by a better console later.
>
> Such a change requires clean up of the register_console() code.
> Otherwise, it would be even harder to follow. Especially, the use
> of has_preferred_console and CON_CONSDEV flag is tricky. The clean
> up is risky. The ordering of consoles is not well defined. And
> any changes tend to break existing user settings.
>
> Do the revert at the least risky solution for now.
>
> Signed-off-by: Petr Mladek <[email protected]>
Acked-by: Sergey Senozhatsky <[email protected]>
-ss
On Thu 2021-01-07 11:38:36, Linus Torvalds wrote:
> On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > Linus, can you take this directly, or is this going through some other
> > tree?
>
> I was _assuming_ that I'd get it through the normal printk pull
> request, it doesn't seem to be that timing-critical.
>
> But if there is nothing else pending, I can certainly take it directly
> as that patch too.
This is the only printk-related fix at the moment.
I have just pushed v2 (updated commit message, tags) into
printk/linux.git for linux-next. It is the patch sent as
https://lore.kernel.org/lkml/[email protected]/
Feel free to push v2 directly. Or I will create pull request the
following week after it spends few days in linux-next.
Best Regards,
Petr
On 1/8/21 9:45 AM, Petr Mladek wrote:
> On Thu 2021-01-07 11:38:36, Linus Torvalds wrote:
>> On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
>> <[email protected]> wrote:
>>> Linus, can you take this directly, or is this going through some other
>>> tree?
>> I was _assuming_ that I'd get it through the normal printk pull
>> request, it doesn't seem to be that timing-critical.
>>
>> But if there is nothing else pending, I can certainly take it directly
>> as that patch too.
> This is the only printk-related fix at the moment.
>
> I have just pushed v2 (updated commit message, tags) into
> printk/linux.git for linux-next. It is the patch sent as
> https://urldefense.com/v3/__https://lore.kernel.org/lkml/[email protected]/__;!!A4F2R9G_pg!P3n1xyAl156-9Gxs8S-k_6obYq-XjXYYWe1_yGYLUmCFRfU7sqjBq4XE1wuZoiZN$
>
> Feel free to push v2 directly. Or I will create pull request the
> following week after it spends few days in linux-next.
Please have it upstream in the upcoming rc since this affects ARC booting.
-Vineet
On Fri, Jan 8, 2021 at 9:45 AM Petr Mladek <[email protected]> wrote:
>
> Feel free to push v2 directly.
Thanks, done.
Linus