[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzMUe5soxMrsFM8V@alley>
Date: Tue, 27 Sep 2022 17:19:23 +0200
From: Petr Mladek <pmladek@...e.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
John Ogness <john.ogness@...utronix.de>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...uxfoundation.org>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Daniel Vetter <daniel@...ll.ch>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Helge Deller <deller@....de>,
Jason Wessel <jason.wessel@...driver.com>,
Daniel Thompson <daniel.thompson@...aro.org>
Subject: Re: [patch RFC 06/29] printk: Protect [un]register_console() with a
mutex
On Tue 2022-09-27 11:56:30, Petr Mladek wrote:
> On Sun 2022-09-11 00:27:41, Thomas Gleixner wrote:
> > Unprotected list walks are a brilliant idea. Especially in the context of
> > hotpluggable consoles.
>
> Yeah, it is crazy. And it is there probably since the beginning.
>
> > @@ -3107,13 +3143,14 @@ void register_console(struct console *ne
> > bool realcon_enabled = false;
> > int err;
> >
> > - for_each_console(con) {
> > + console_list_lock();
>
> Hmm, the new mutex is really nasty. It has very strange semantic.
> It makes the locking even more complicated.
Please, continue the discussion in the reply to the v1 patchset,
see https://lore.kernel.org/r/YzMT27FVllY3u05k@alley
I send it to this RFC by mistake.
I am sorry for the mess.
Best Regards,
Petr
Powered by blists - more mailing lists