On (21/06/29 16:33), Petr Mladek wrote:
> The standard printk() tries to flush the message to the console
> immediately. It tries to take the console lock. If the lock is
> already taken then the current owner is responsible for flushing
> even the new message.
>
> There is a small race window between checking whether a new message is
> available and releasing the console lock. It is solved by re-checking
> the state after releasing the console lock. If the check is positive
> then console_unlock() tries to take the lock again and process the new
> message as well.
[..]
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 142a58d124d9..87411084075e 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2545,6 +2545,7 @@ void console_unlock(void)
> bool do_cond_resched, retry;
> struct printk_info info;
> struct printk_record r;
> + u64 next_seq;
>
> if (console_suspended) {
> up_console_sem();
> @@ -2654,8 +2655,10 @@ void console_unlock(void)
> cond_resched();
> }
>
> - console_locked = 0;
> + /* Get consistent value of the next-to-be-used sequence number. */
> + next_seq = console_seq;
>
> + console_locked = 0;
> up_console_sem();
>
> /*
> @@ -2664,7 +2667,7 @@ void console_unlock(void)
> * there's a new owner and the console_unlock() from them will do the
> * flush, no worries.
> */
> - retry = prb_read_valid(prb, console_seq, NULL);
> + retry = prb_read_valid(prb, next_seq, NULL);
> printk_safe_exit_irqrestore(flags);
>
> if (retry && console_trylock())
Maybe it's too late here in my time zone, but what are the consequences
of this race?
`retry` can be falsely set, console_trylock() does not spin on owner,
so the context that just released the lock can grab it again only if
it's unlocked. For the context that just has released the console_sem
and then acquired it again, because of the race, - console_seq will be
valid after it acquires the lock, then it'll jump to `retry` and
re-validated the console_seq - prb_read_valid(). If it's valid, it'll
print the message; and should another CPU printk that CPU will spin on
owner and then the current console_sem owner will yield to it via
console_lock_spinning branch.
One way or the other, good catch and nice to have it fixed.
Acked-by: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx>
