Messages in this thread | | | From | John Ogness <> | Subject | Re: replay log: Re: [PATCH printk v4 38/39] printk: relieve console_lock of list synchronization duties | Date | Tue, 15 Nov 2022 17:47:12 +0106 |
| |
On 2022-11-15, Petr Mladek <pmladek@suse.com> wrote: > On Mon 2022-11-14 17:35:31, John Ogness wrote: >> --- a/kernel/printk/printk.c >> +++ b/kernel/printk/printk.c >> @@ -3334,6 +3330,11 @@ void register_console(struct console *newcon) >> * boot console that is the furthest behind. >> */ >> if (bootcon_registered && !keep_bootcon) { >> + /* >> + * Hold the console_lock to guarantee safe access to >> + * console->seq. >> + */ >> + console_lock(); >> for_each_console(con) { >> if ((con->flags & CON_BOOT) && >> (con->flags & CON_ENABLED) && >> @@ -3341,6 +3342,7 @@ void register_console(struct console *newcon) >> newcon->seq = con->seq; >> } >> } >> + console_unlock(); > > Thinking more about it. This console_unlock() will actually cause > flushing the boot consoles. A solution would be to call > console_flush_all() here.
console_flush_all() requires the console_lock, so I don't think it would be different.
The correct solution would be to recognize if nextcon is taking over a bootcon. If yes, that bootcon could be unregistered right here with unregister_console_locked() and then seq for nextcon set appropriately to perfectly take over.
But we will need to think about how we could recognize the same device. I was thinking about if consoles hat some attribute showing their io-membase or something so that it could be clear that the two are the same hardware.
> And we could/should solve this in a separate patch. This code was not > locked before. It is a corner case. It could be solved later.
Agreed.
John
| |