Re: [PATCH for-6.4] printk: Unregister boot consoles on register of 1st real console

From: Petr Mladek
Date: Thu Mar 09 2023 - 06:19:32 EST


On Thu 2022-02-24 05:40:33, Lukas Wunner wrote:
> The code comment preceding register_console() claims that:
>
> "There are two types of consoles - bootconsoles (early_printk) and
> "real" consoles (everything which is not a bootconsole) which are
> handled differently. [...]
> As soon as a "real" console is registered, all bootconsoles
> will be unregistered automatically."
>
> But that's not what the code does: The code unregisters bootconsoles
> only when the *preferred* console registers, i.e. the last one on the
> command line.

Yes

> If that console's driver never registers (e.g. because
> it is disabled in the kernel config), bootconsoles stay around
> indefinitely.

They are actually unregistered by a late_initcall, see
printk_late_init().

> Should the command line contain both a bootconsole as
> well as a real console on the same serial port, all messages are logged
> twice once the real console registers.
>
> Moreover, the log buffer is replayed once the real console registers
> even though the messages were already emitted by the bootconsole.

Yes, the messages might get duplicated until the printk_late_init()
is called. And the log might get replayed even though it was already
printed on the boot console.

> Amend the code to be congruent with the above-quoted code comment and
> thereby avoid these issues.

I am afraid that we could not change the behavior. It would cause
the opposite problem. It might might remove the boot consoles too early
and some messages might be missing on the corresponding console.
Also the log might get replayed on the "preferred" console.
People would see this as regression.

The only acceptable solution would be to do the right thing.
I mean to match the corresponding boot and real consoles.
Then we could remove the boot console exactly when it is replaced
by the real one. It would prevent any duplicated or lost messages.

In the meantime, we could only fix the comment so that it describes
the current behavior.

Best Regards,
Petr

Best Regards,
Petr