lkml.org 
[lkml]   [2022]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH printk v4 14/15] printk: extend console_lock for proper kthread support
Date
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@linutronix.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

\
 
 \ /
  Last update: 2022-04-21 23:41    [W:0.259 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site