Messages in this thread | | | From | John Ogness <> | Subject | Re: [PATCH printk v4 14/15] printk: extend console_lock for proper kthread support | Date | Thu, 21 Apr 2022 23:46:24 +0206 |
| |
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
| |