lkml.org 
[lkml]   [2022]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: replay log: Re: [PATCH printk v4 38/39] printk: relieve console_lock of list synchronization duties
Date
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

\
 
 \ /
  Last update: 2022-11-15 17:41    [W:0.272 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site