Re: [PATCH printk v1 07/10] console: add write_atomic interface

Sergey Senozhatsky
2021-08-31T02:55:11Z

On (21/08/03 15:18), John Ogness wrote:
[..]
> @@ -1993,6 +1993,16 @@ static int console_trylock_spinning(void)
> bool spin = false;
> unsigned long flags;
>
> +#ifdef CONFIG_SMP
> + /*
> + * CPUs holding the printk cpulock must not spin on any lock. Even
> + * console_trylock() must not be called because its implementation
> + * uses spinlocks.
> + */
> + if (atomic_read(&printk_cpulock_owner) == smp_processor_id())
> + return 0;
> +#endif
> +
> if (console_trylock())
> return 1;
>
> @@ -2719,7 +2729,17 @@ static int have_callable_console(void)
> */
> static inline int can_use_console(void)
> {
> - return cpu_online(raw_smp_processor_id()) || have_callable_console();
> + int cpu = raw_smp_processor_id();
> +#ifdef CONFIG_SMP
> + /*
> + * CPUs holding the printk cpulock must not spin on any lock.
> + * Allowing console usage could call into the spinlocks of the
> + * various console drivers.
> + */
> + if (atomic_read(&printk_cpulock_owner) == cpu)
> + return 0;

I guess the only reason this is done in can_use_console() is
console_flush_on_panic()?

Because otherwise, I think, we can move this check to vprintk_emit().

can_use_console() can be called from preemptible() context. But
if it's called from preemptible() then we know that this is not
printk()/NMI path (but console_device() and friends instead) and
that this CPU is definitely not holding printk CPU lock.

console_trylock_spinning() and console_unlock()->can_use_console()
follow each other

if (console_trylock_spinning())
console_unlock();

so a single `atomic_read(&printk_cpulock_owner) == cpu` can suffice.

Now we get to the console_flush_on_panic(), which still calls console_unlock(),
iterates over messages, but when called by the CPU that owns printk_lock,
just skips all the messages. But there is no point in calling console_unlock()
in such a case, we can check if we're printk_cpulock_owner and bail out if so.

Or am I missing something?