[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o7uxugbr.fsf@jogness.linutronix.de>
Date: Fri, 30 Sep 2022 15:50:56 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>,
Doug Anderson <dianders@...omium.org>
Cc: 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 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.
John
Powered by blists - more mailing lists