[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yzcm6Fb6FJGbspgY@alley>
Date: Fri, 30 Sep 2022 19:27:04 +0200
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Doug Anderson <dianders@...omium.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Jason Wessel <jason.wessel@...driver.com>,
Daniel Thompson <daniel.thompson@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Aaron Tomlin <atomlin@...hat.com>,
Luis Chamberlain <mcgrof@...nel.org>,
kgdb-bugreport@...ts.sourceforge.net, linux-serial@...r.kernel.org
Subject: Re: [PATCH printk 10/18] kgbd: Pretend that console list walk is safe
On Fri 2022-09-30 15:50:56, John Ogness wrote:
> On 2022-09-30, Petr Mladek <pmladek@...e.com> wrote:
> > Anyway, what about using the later added SRCU walk here?
> > After all, this is exactly what RCU is for, isn't it?
>
> So I think a lot of the problems with this series is that SRCU is
> introduced too late. We are debating things in patch 6 that are
> irrelevant by patch 12.
> I will rework the series so that the changes come in the following
> order:
>
> 1. provide an atomic console_is_enabled()
>
> 2. convert the list to SRCU
>
> 3. move all iterators from console_lock()/console_trylock() to SRCU
>
> Step 3 may result in console_lock()/console_trylock() calls disappearing
> or relocating to where they are needed for non-list-synchronization
> purposes.
I agree that introding SRCU as early as possible would
help. The current patchset converts the same code several times...
Best Regards,
Petr
Powered by blists - more mailing lists