On (04/23/19 09:48), Steven Rostedt wrote:
> > RFC
> >
> > Normally, we grab console_sem lock before we iterate consoles
> > list, which is necessary if we want to be race free. The only exception
> > to this rule is console_flush_on_panic(). However, it seems that we are
> > not fully race free - register_console() iterates console drivers list
> > in unsafe manner in several places. E.g. the following scenarion:
> >
> > CPU0 CPU1
> > register_console() unregister_console()
> > console_lock()
> > for_each_console() // modify console_drivers
> > con->foo kfree(con)
> >
> > So I have two quick-n-dirty patches, which remove unsafe console list
> > access.
> >
> > What do you think?
>
> I just skimmed the patches and haven't done a thorough review, but the
> concept seems sane to me.
Thank you Steven. Let me know if anything doesn't work for you.
I have vague memories of a kernel Oops at con->foo dereferencing
(saw a message on linux-rt-users list a while ago, if I'm not
mistaken). And it seems that we have some races in printk code.
-ss
