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

[Xiaochun Li]

On 5/18/2026 6:16 PM, John Ogness wrote:
> 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

Thanks for your prompt reply. I will follow your suggestions to work out a 
proper solution based on the cleanup patch series.

Best regards,
Xiaochun Li