[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190423094801.377b8059@gandalf.local.home>
Date: Tue, 23 Apr 2019 09:48:01 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC][PATCH 0/2] Access console drivers list under console_sem
On Tue, 23 Apr 2019 15:25:09 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> wrote:
> Petr, Steven,
>
> 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.
-- Steve
>
> Sergey Senozhatsky (2):
> printk: lock console_sem before we unregister boot consoles
> printk: take console_sem when accessing console drivers list
>
> kernel/printk/printk.c | 117 ++++++++++++++++++++++++-----------------
> 1 file changed, 69 insertions(+), 48 deletions(-)
>
Powered by blists - more mailing lists