Re: [PATCH v1] printk: Unconditionally unregister boot consoles when any real console appears

[John Ogness]

Hi Xiaochun,

On 2026-05-18, Xiaochun Li <lixiaochun@xxxxxxxxxxxxxx> wrote:
> The design of kernel message printing ensures that boot consoles are
> temporary and should be unregistered once a real console appears,
> preventing duplicate output without any loss of kernel messages.
>
> But currently, when multiple "console=" parameters are specified
> (e.g., console=ttyS0 console=ttyS1) together with a boot console
> (earlyprintk=ttyS0 and/or earlycon=uart,io,0x3f8), the boot console
> remains active indefinitely. As a result, after the real console
> active, each kernel message line is printed twice consecutively that
> is not as expected.

Although specifying multiple consoles using the same driver is improper
usage, I would still consider this a bug. Thanks for pointing this out.

(The fact that you cannot specify multiple consoles with the same driver
is a ridiculous historical artifact... but that is another topic.)

> Currently, register_console() unregisters boot consoles only when the
> newly registered console has CON_CONSDEV (i.e., it is the preferred
> console). However, when multiple "console=" arguments are given for
> the same driver (e.g., 8250), the try_enable_preferred_console()
> matches only the first console_cmdline entry and returns immediately.
> The enabled real console (ttyS0) is therefore not the preferred one
> and does not set CON_CONSDEV, because preferred_console points to the
> last entry (ttyS1). Consequently, the boot console is never unregistered.
>
> Fix this issue by removing the CON_CONSDEV requirement and
> unregistering all boot consoles whenever any real console
> (i.e., any console without CON_BOOT flag) is registered

I do not think this is the correct fix. It relies on the buggy
unregister_console_locked() code that even warns:

     * <HISTORICAL>
     * If this isn't the last console and it has CON_CONSDEV set, we
     * need to set it on the next preferred console.
     * </HISTORICAL>
     *
     * The above makes no sense as there is no guarantee that the next
     * console has any device attached. Oh well....

I expect that the correct fix would be to make sure the registered
regular console gets CON_CONSDEV if the preferred console could not be
registered.

Or maybe the unregister_console_locked() should be fixed so that there
is a proper fallback when a CON_CONSDEV console unregisters.

The preferred console code is quite tricky and is even in the process of
being cleaned up. (Although the bug is present after applying the
cleanup series as well.)

John

[0] https://lore.kernel.org/lkml/20260423130015.85175-1-pmladek@xxxxxxxx