[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y3z8HOt0yOd1nceY@kroah.com>
Date: Tue, 22 Nov 2022 17:43:08 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: John Ogness <john.ogness@...utronix.de>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org,
Jason Wessel <jason.wessel@...driver.com>,
Daniel Thompson <daniel.thompson@...aro.org>,
Douglas Anderson <dianders@...omium.org>,
Jiri Slaby <jirislaby@...nel.org>,
kgdb-bugreport@...ts.sourceforge.net, linux-serial@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Johannes Berg <johannes@...solutions.net>,
linux-um@...ts.infradead.org, Aaron Tomlin <atomlin@...hat.com>,
Luis Chamberlain <mcgrof@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Lukas Wunner <lukas@...ner.de>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-m68k@...ts.linux-m68k.org, Ard Biesheuvel <ardb@...nel.org>,
linux-efi@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org,
Michal Simek <michal.simek@...inx.com>,
Peter Zijlstra <peterz@...radead.org>,
Mathias Nyman <mathias.nyman@...ux.intel.com>,
linux-usb@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
Helge Deller <deller@....de>,
Thomas Zimmermann <tzimmermann@...e.de>,
Javier Martinez Canillas <javierm@...hat.com>,
Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Tom Rix <trix@...hat.com>, linux-fbdev@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH printk v5 00/40] reduce console_lock scope
On Wed, Nov 16, 2022 at 05:27:12PM +0106, John Ogness wrote:
> This is v5 of a series to prepare for threaded/atomic
> printing. v4 is here [0]. This series focuses on reducing the
> scope of the BKL console_lock. It achieves this by switching to
> SRCU and a dedicated mutex for console list iteration and
> modification, respectively. The console_lock will no longer
> offer this protection.
>
> Also, during the review of v2 it came to our attention that
> many console drivers are checking CON_ENABLED to see if they
> are registered. Because this flag can change without
> unregistering and because this flag does not represent an
> atomic point when an (un)registration process is complete,
> a new console_is_registered() function is introduced. This
> function uses the console_list_lock to synchronize with the
> (un)registration process to provide a reliable status.
>
> All users of the console_lock for list iteration have been
> modified. For the call sites where the console_lock is still
> needed (for other reasons), comments are added to explain
> exactly why the console_lock is needed.
>
> All users of CON_ENABLED for registration status have been
> modified to use console_is_registered(). Note that there are
> still users of CON_ENABLED, but this is for legitimate purposes
> about a registered console being able to print.
>
> The base commit for this series is from Paul McKenney's RCU tree
> and provides an NMI-safe SRCU implementation [1]. Without the
> NMI-safe SRCU implementation, this series is not less safe than
> mainline. But we will need the NMI-safe SRCU implementation for
> atomic consoles anyway, so we might as well get it in
> now. Especially since it _does_ increase the reliability for
> mainline in the panic path.
>
> Changes since v4:
>
> printk:
>
> - Introduce console_init_seq() to handle the now rather complex
> procedure to find an appropriate start sequence number for a
> new console upon registration.
>
> - When registering a non-boot console and boot consoles are
> registered, try to flush all the consoles to get the next @seq
> value before falling back to use the @seq of the enabled boot
> console that is furthest behind.
>
> - For console_force_preferred_locked(), make the console the
> head of the console list.
>
Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Powered by blists - more mailing lists