[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wnfiyv1z.fsf@jogness.linutronix.de>
Date: Thu, 21 Apr 2022 23:46:24 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH printk v4 14/15] printk: extend console_lock for proper
kthread support
Hi Petr,
If v4 ends up being acceptable for linux-next, I would request you fold
a couple cosmetic changes into this patch.
On 2022-04-21, John Ogness <john.ogness@...utronix.de> wrote:
> +/*
> + * Since the kthread printers do not acquire the console_lock but do need to
> + * access @flags, they could experience races because other tasks
> + * (synchronizing using the console_lock) can modify @flags. These macros are
> + * available to at least provide atomic variable updates so that the kthread
> + * printers can see consistent values.
This last sentence is bad. It should not use the words "atomic" and
"updates". Please change it to:
These macros are available to store the new value in a way that will
provide consistent load values for kthread printers. Tasks using
these macros must still do so under the console_lock.
[...]
> EXPORT_SYMBOL(console_stop);
>
> +
Please remove this accidental blank line.
> void console_start(struct console *console)
> {
> console_lock();
> - console->flags |= CON_ENABLED;
> - console_unlock();
>
> - /* Wake the newly enabled kthread printer. */
> - wake_up_klogd();
> + /* Can cause races for printk_kthread_func(). */
> + console_flags_set(console->flags, CON_ENABLED);
>
> + console_unlock();
> __pr_flush(console, 1000, true);
> }
> EXPORT_SYMBOL(console_start);
John
Powered by blists - more mailing lists