Messages in this thread | | | Date | Thu, 25 Apr 2019 14:19:44 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCH 2/2] printk: take console_sem when accessing console drivers list |
| |
On (04/24/19 17:13), Petr Mladek wrote: > > /* > > * before we register a new CON_BOOT console, make sure we don't > > @@ -2691,6 +2696,7 @@ void register_console(struct console *newcon) > > if (!(bcon->flags & CON_BOOT)) { > > pr_info("Too late to register bootconsole %s%d\n", > > newcon->name, newcon->index); > > + console_unlock(); > > return; > > } > > } > > @@ -2701,6 +2707,7 @@ void register_console(struct console *newcon) > > > > if (!has_preferred || bcon || !console_drivers) > > has_preferred = preferred_console >= 0; > > + console_unlock();
Thanks for taking a look!
> We should keep it until the console is added into the list. Otherwise > there are races with accessing the static has_preferred and > the global preferred_console variables.
We don't modify `preferred_console' in register_console(), only read-access it. Write-access, at the same time, is not completely race free. That global `preferred_console' is modified from
add_preferred_console() -> __add_preferred_console() -> WRITE preferred_console console_setup() -> __add_preferred_console() -> WRITE preferred_console
So `preferred_console' is not WRITE protected by console_sem, that's why I didn't make sure to READ protected it in register_console().
As of static `has_preferred'... I kind of couldn't figure out if we really need to protect it, but can do.
> Also the value of bcon should stay synchronized until we decide > about replaying the log.
Good catch. So we, basically, can do the same thing as we did to __unregister_console(): factor out the registration code and call that new __register_console() under console_lock, and do console_unlock()/console_lock() after we add console to the list, but before we unregister boot consoles.
Except for one small detail:
> IMHO, the only danger might be when con->match() or con->setup() > would want to take console_lock() as well. I checked few drivers > and they looked safe. But I did not check all of them. > > What do you think, please?
That's a hard question. I would assume that ->match() has no business in console_sem; but I'm not completely sure about ->setup().
E.g. 8250 does take console_sem during port configuration: config_port() serial8250_config_port() autoconfig_irq() console_lock()
But it doesn't look like we hit this path from ->setup(); seems to be early serial setup stage.
So may be we can move the whole thing under console_sem.
-ss
| |