linux-kernel - Re: Do not delay boot when printing log to serial console during startup?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y3JGcQyuW+ydwkYE@alley>
Date:   Mon, 14 Nov 2022 14:45:21 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        John Ogness <john.ogness@...utronix.de>,
        linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Do not delay boot when printing log to serial console during
 startup?

Adding John into Cc. He is working on introducing printk kthreads that
might allow to handle consoles asynchronously.

On Tue 2022-10-11 11:03:39, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> We boot our systems generally with the serial console enabled
> `console=ttyS0,115200n8`, and noticed that initializing the console takes at
> least one second.
> 
>     $ dmesg | grep -e 'DMI:' -e 'printk: console'
>     [    0.000000] DMI: Dell Inc. PowerEdge R7525/05Y13N, BIOS 2.7.3
> 03/30/2022
>     [    2.691432] printk: console [tty0] enabled
>     [    5.414384] printk: console [ttyS0] enabled
> 
>     $ dmesg | grep -e 'DMI:' -e 'printk:'
>     [    0.000000] DMI: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.22.0
> 07/13/2022
>     [    0.146953] printk: console [tty0] enabled
>     [    1.374382] printk: console [ttyS0] enabled
> 
>     $ dmesg | grep -e 'DMI:' -e 'printk: console'
>     [    0.000000] DMI: Dell Inc. PowerEdge R7425/08V001, BIOS 1.6.7
> 10/29/2018
>     [    1.589543] printk: console [tty0] enabled
>     [    3.057770] printk: console [ttyS0] enabled
> 
>     $ dmesg | grep -e 'DMI:' -e 'printk: console'
>     [    0.000000] DMI: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10
> Plus, BIOS A42 12/03/2021
>     [    5.171202] printk: console [tty0] enabled
>     [    8.066602] printk: console [ttyS0] enabled
> 
> `initcall_debug` shows:
> 
>     [    0.190491] calling  univ8250_console_init+0x0/0x2b @ 0
>     [    1.488645] printk: console [ttyS0] enabled
>     [    1.492945] initcall univ8250_console_init+0x0/0x2b returned 0 after
> 0 usecs
> 
> (Note, that the “after time” by initcall does not match the timestamp at the
> beginning.)

The message "printk: console [ttyS0] enabled" is printed almost at the
end of register_console(). It happens after all previously printed
messages reach the console.

It might take a long time to show all messages on slow serial consoles.


> So it looks to me like, that the already recorded messages are printed out
> over the serial console first, before it continues. The documentation of
> `register_console()` in `kernel/printk/printk.c` confirms that:
> >
> >  * The console driver calls this routine during kernel initialization
> >  * to register the console printing procedure with printk() and to
> >  * print any messages that were printed by the kernel before the
> >  * console driver was initialized.

Most people want to see all messages. Any previous warning or error might
the reason why the system crashed later.

If you want faster boot, you might consider using "quiet" or
loglevel=<some low number> on the kernel command line. It will
show only the most important messages on the console.


> Is there an option to enable the serial console but send the messages to it
> asynchronously so it does not hold up the boot?

We have been trying to get this into upstream for years. It is not
that easy. Asynchronous handling increases the risk that a console
will not show the last important messages when things go wrong.

Anyway, we are still trying. One puzzle of this effort is just
being reviewed in this thread,
https://lore.kernel.org/r/20221107141638.3790965-1-john.ogness@linutronix.de

Best Regards,
Petr