Messages in this thread | | | Date | Thu, 13 Apr 2023 15:42:08 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH printk v1 02/18] printk: Add NMI check to down_trylock_console_sem() |
| |
On Fri 2023-03-17 12:43:56, John Ogness wrote: > On 2023-03-07, Petr Mladek <pmladek@suse.com> wrote: > > So that this change would cause a non-paired console_unlock(). > > And console_unlock might still deadlock on the console_sem->lock. > > Yes, but at least it would have flushed beforehand. > > > One solution would be to call console_flush_all() directly in > > console_flush_on_panic() without taking console_lock(). > > > > It should not be worse than the current code which ignores > > the console_trylock() return value. > > I think your suggestion is acceptable. > > > Note that it mostly works because console_flush_on_panic() is called > > when other CPUs are supposed to be stopped. > > > > We only would need to prevent other CPUs from flushing messages > > as well if they were still running by chance. But we actually already > > do this, see abandon_console_lock_in_panic(). Well, we should > > make sure that the abandon_console_lock_in_panic() check is > > done before flushing the first message. > > > > All these changes together would prevent deadlock on > > console_sem->lock. But the synchronization "guarantees" should stay > > the same. > > We could also update console_trylock() and console_lock() to fail and > infinitely sleep, respectively, when abandon_console_lock_in_panic() is > true. That would prevent CPUs from newly acquiring the console lock and > interfering with the panic CPU.
Interesting idea. It should be safe after panic() tries to stop the CPUs. But I am slightly worried to do this earlier.
I wonder if it might block, for example, trigger_all_cpu_backtrace() that is called when (panic_print & PANIC_PRINT_ALL_CPU_BT) bit is set.
Best Regards. Petr
| |