Re: [PATCH v3] printk: Remove remaining boot consoles when a real console exists

[Petr Mladek]

On Tue 2026-08-25 14:35:10, Xiaochun Li wrote:
> On 8/21/2026 3:17 PM, Xiaochun Li wrote:
> > Boot consoles are temporary and should be removed once a real console is
> > available. However, the late init cleanup currently only unregisters boot
> > consoles that use init section memory. Other boot consoles are expected
> > to be removed when the real preferred console is registered.
> > 
> > This does not cover cases where a real console has registered, but the
> > boot console was not removed because the real console did not become the
> > preferred console. For example, with multiple console= parameters using
> > the same driver, a real 8250 console may be enabled while the early
> > console remains registered. The result is duplicate printk output from
> > both consoles.
> > 
> > In the mailing list discussion, two possible approaches were suggested
> > to fix this problem [1]. This patch implements the first one: during
> > printk_late_init(), check whether at least one real console is already
> > registered. If so, unregister all remaining boot consoles. If no real
> > console exists yet, keep the existing behavior and unregister only boot
> > consoles that reference init section memory, avoiding a period with no
> > console output while waiting for a deferred or modular real console.
> > 
> Sashiko AI raised the following concern about v3:
> 
> | Does this logic unintentionally unregister boot consoles when an unrelated
> | real console is present?
> | If a system boots with multiple consoles (like console=tty0 console=ttyS0
> | earlycon) and an unrelated real console like tty0 (or dummycon) registers
> | early, have_real_console will evaluate to true here.
> | Because have_real_console is true, the init-section memory check is bypassed
> | entirely, and the boot console is unconditionally destroyed:
> |       if (keep_bootcon || !have_real_console) {
> |               // bypassed
> |       }
> |       unregister_console_locked(con);
> | If the real driver for ttyS0 is modular and has not loaded yet, won't this
> | leave the serial console dead and cause a loss of console output during the
> | window between late_initcall and the module loading?
> 
> I think this concern is valid for the case where an unrelated real console
> has registered while the real console corresponding to a remaining boot
> console is delayed by deferred probing or module loading.
> 
> `have_real_console` is intentionally global in this patch. The purpose is to
> handle the case where a real console has already been registered but has not
> become `CON_CONSDEV`. In that situation, the existing registration path does
> not remove the remaining boot consoles, and duplicate output may persist.
> 
> Therefore, when `printk_late_init()` observes any registered real console,
> this patch deliberately removes all remaining boot consoles without trying
> to establish a one-to-one correspondence between them. This does introduce
> a trade-off: a boot console may be removed even though its corresponding real
> console has not registered yet, creating a temporary loss of output on that
> console.
> 
> Unregistering the boot console does not remove records from the printk ring
> buffer. A later real console may replay some or all of those records,
> depending on its flags and sequence initialization. However, this does not
> guarantee that messages generated during the gap will be visible, especially
> if the system fails before the real console registers or if the records are
> overwritten.
> 
> This patch implements only idea 1 from [0]. It does not solve the problem
> comprehensively. We plan to investigate idea 2, based on the work in [1],
> which should allow the cleanup decision to be made with more precise
> information about the corresponding real console.
> 
> Do you think the trade-off described above is acceptable for this patch?

I believe that this is acceptable. The same problem existed even
before. The boot consoles are unregistered at the end of
register_console() when the so-called preferred console gets
registered. The preferred console is defined by
the last console= on the command line.

The preferred console might be the graphical ttyX. So the serial
early console might get unregistered before the proper serial
console driver gets registered and it might cause the above
described gap.

More details:

I have just double checked the code in register_console().
It looks like:

void register_console(struct console *newcon)
{
[...]
	/*
	 * By unregistering the bootconsoles after we enable the real console
	 * we get the "console xxx enabled" message on all the consoles -
	 * boot consoles, real consoles, etc - this is to ensure that end
	 * users know there might be something in the kernel's log buffer that
	 * went to the bootconsole (that they do not see on the real console)
	 */
	con_printk(KERN_INFO, newcon, "enabled\n");
	if (bootcon_registered &&
	    ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV) &&
	    !keep_bootcon) {
		struct hlist_node *tmp;

		hlist_for_each_entry_safe(con, tmp, &console_list, node) {
			if (con->flags & CON_BOOT)
				unregister_console_locked(con);
		}
	}
[...]
}

The comment above the code says that the boot consoles are removed when
a real console gets registered. But it is _not_ right.

The meaning of the CON_CONSDEV flags is historically pretty
complicated.

The name CON_CONSDEV suggests that it should be set for
the console driver which is associated with /dev/console.
But it is just the best effort.

The driver associated with /dev/console is selected by
console_device(). And it returns the first driver where
con->device() exists and return !NULL. It does not check
the flag at all.

Unfortunately, con->device() might returns NULL in
register_console() and some real value later. It is related
to the ordering of initialization of various subsystems.
Anyway, the result is that register_console() must guess.

Plus there is the rule that the preferred console (last on
the command line) should get associated with /dev/console.
For this, register_console() must put the preferred console
to be first in console_list.

Now, back to the best effort. CON_CONSDEV is set by:

   + try_enable_preferred_console() _only_ for the preferred console.
     This function is used when some console is preferred on
     the command line or via SPCR or the device tree.

   + try_enable_default_console() for real console drivers.
     This function is used when there is no preferred console.

   + register_console() and unregister_console_locked() for
     the 1st console in the console_list. It is a hack
     to make sure that at least one console has the flag set.
     And it might be set even for a boot console.

   + console_force_preferred_locked() for the given console.
     Some platforms have their own preferred console.

Summary:

It is complicated. But in short:

   1. It might happen that CON_CONSDEV points to boot console
      => register_console() does not remove boot consoles
      when a real console (not the preferred_console one)
      gets registered.

      This is why it makes sense to remove them in printk_late_init().

      => this patch makes sense.


   2. register_console() already might remove boot consoles
      before the corresponding real driver gets registered.

      => the race already exist.

      => this patch looks acceptable to me.

Best Regards,
Petr

PS: I am going to take a break, coffee, and actually review the patch ;-)