Message ID | 20220924000454.3319186-1-john.ogness@linutronix.de |
---|---|
Headers | show |
Series | preparation for threaded/atomic printing | expand |
On 2022-09-24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > These all look great to me, thanks for resending them. > > Do you want them to go through my serial/tty tree, or is there some > other tree to take them through (printk?) Thanks Greg. but I would prefer they go through the printk tree. In particular, I want Petr to have the chance to review patches 15-18. > If they are to go through someone else's tree, feel free to add: > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks! John
Hi, On Fri, Sep 23, 2022 at 5:05 PM John Ogness <john.ogness@linutronix.de> wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > Unprotected list walks are not necessarily safe. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: John Ogness <john.ogness@linutronix.de> > Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> > --- > drivers/tty/serial/kgdboc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c > index 79b7db8580e0..af2aa76bae15 100644 > --- a/drivers/tty/serial/kgdboc.c > +++ b/drivers/tty/serial/kgdboc.c > @@ -193,7 +193,8 @@ static int configure_kgdboc(void) > if (!p) > goto noconfig; > > - for_each_console(cons) { > + console_list_lock(); > + for_each_registered_console(cons) { > int idx; > if (cons->device && cons->device(cons, &idx) == p && > idx == tty_line) { > @@ -201,6 +202,7 @@ static int configure_kgdboc(void) > break; > } > } > + console_list_unlock(); Seems right to me, thanks! Reviewed-by: Douglas Anderson <dianders@chromium.org>
On Sat 2022-09-24 02:10:36, John Ogness wrote: > Hi, > > This series is essentially the first 18 patches of tglx's RFC series > [0] with only minor changes in comments and commit messages. It's > purpose is to lay the groundwork for the upcoming threaded/atomic > console printing posted as the RFC series and demonstrated at > LPC2022 [1]. > > This series is interesting for mainline because it cleans up various > code and documentation quirks discovered while working on the new > console printing implementation. > > Aside from cleanups, the main features introduced here are: > > - Converts the console's DIY linked list implementation to hlist. > > - Introduces a console list lock (mutex) so that readers (such as > /proc/consoles) can safely iterate the consoles without blocking > console printing. > > - Adds SRCU support to the console list to prepare for safe console > list iterating from any context. > > - Refactors buffer handling to prepare for per-console, per-cpu, > per-context atomic printing. > > The series has the following parts: > > Patches 1 - 5: Cleanups > > Patches 6 - 12: Locking and list conversion > > Patches 13 - 18: Improved output buffer handling to prepare for > code sharing > > Thomas Gleixner (18): > printk: Make pr_flush() static > printk: Declare log_wait properly > printk: Remove write only variable nr_ext_console_drivers > printk: Remove bogus comment vs. boot consoles > printk: Mark __printk percpu data ready __ro_after_init JFYI, I have pushed the first 5 cleanup patches into printk/linux.git, branch rework/kthreads. The aim is to get them into 6.1. The rest of the patchset is still being discussed. Best Regards, Petr
On Sat 2022-09-24 02:10:45, John Ogness wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > Unprotected list walks are not necessarily safe. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: John Ogness <john.ogness@linutronix.de> > Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> It looks correct in principle. There is still a discussion [1] whether to introduce console_list_lock() or use the existing console_lock(), see https://lore.kernel.org/r/20220924000454.3319186-7-john.ogness@linutronix.de Depending on the result of the discussion, with either console_list_lock() or console_lock(): Reviewed-by: Petr Mladek <pmladek@suse.com> Best Regards, Petr