Messages in this thread | | | Date | Wed, 26 Jan 2022 18:18:38 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH 2/4] printk: disable optimistic spin during panic |
| |
On (22/01/21 11:02), Stephen Brennan wrote: > A CPU executing with console lock spinning enabled might be halted > during a panic. Before the panicking CPU calls console_flush_on_panic(), > it may call console_trylock(), which attempts to optimistically spin, > deadlocking the panic CPU: > > CPU 0 (panic CPU) CPU 1 > ----------------- ------ > printk() { > vprintk_func() { > vprintk_default() { > vprintk_emit() { > console_unlock() { > console_lock_spinning_enable(); > ... printing to console ... > panic() { > crash_smp_send_stop() { > NMI -------------------> HALT > } > atomic_notifier_call_chain() { > printk() { > ... > console_trylock_spinnning() { > // optimistic spin infinitely
[..]
> +++ b/kernel/printk/printk.c > @@ -1843,6 +1843,16 @@ static int console_trylock_spinning(void) > if (console_trylock()) > return 1; > > + /* > + * It's unsafe to spin once a panic has begun. If we are the > + * panic CPU, we may have already halted the owner of the > + * console_sem. If we are not the panic CPU, then we should > + * avoid taking console_sem, so the panic CPU has a better > + * chance of cleanly acquiring it later. > + */ > + if (panic_in_progress()) > + return 0;
Is there something that prevents panic CPU from NMI hlt CPU which is in console_trylock() under raw_spin_lock_irqsave()?
CPU0 CPU1 console_trylock_spinnning() console_trylock() down_trylock() raw_spin_lock_irqsave(&sem->lock)
panic() crash_smp_send_stop() NMI -> HALT
| |