[lkml]   [2019]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

E.g. 8250 does take console_sem during port configuration:

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.


 \ /
  Last update: 2019-04-25 07:20    [W:0.038 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site