Message ID | 20221116162152.193147-1-john.ogness@linutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | reduce console_lock scope | expand |
On Wed 2022-11-16 17:27:12, 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. The patchset looks ready for linux-next from my POV. I am going to push it there right now to get as much testing as possible before the merge window. Any review and comments are still appreciate. We could always take it back if some critical problems are discovered and can't be solved easily. Best Regards, Petr
On Fri 2022-11-18 12:22:58, Petr Mladek wrote: > On Wed 2022-11-16 17:27:12, 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. > > The patchset looks ready for linux-next from my POV. > > I am going to push it there right now to get as much testing > as possible before the merge window. JFYI, the patchset is committed in printk/linux.git, branch rework/console-list-lock. I'll eventually merge it into rework/kthreads. But I wanted to have it separated until it gets some more testing in linux-next and eventually some more review. Best Regards, Petr
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@linuxfoundation.org>