Messages in this thread | | | Date | Thu, 21 Jun 2018 10:23:23 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks |
| |
On (06/20/18 14:30), Andrew Morton wrote: > > From: Hoeun Ryu <hoeun.ryu@lge.com> > > > > Many console device drivers hold the uart_port->lock spinlock with irq enabled > > (using spin_lock()) while the device drivers are writing characters to their devices, > > but the device drivers just try to hold the spin lock (using spin_trylock()) if > > "oops_in_progress" is equal or greater than 1 to avoid deadlocks. > > > > There is a case ocurring a deadlock related to the lock and oops_in_progress. A CPU > > could be stopped by smp_send_stop() while it was holding the port lock because irq was > > enabled. Once a CPU stops, it doesn't respond interrupts anymore and the lock stays > > locked forever. > > > > console_flush_on_panic() is called during panic() and it eventually holds the uart > > lock but the lock is held by another stopped CPU and it is a deadlock. By moving > > bust_spinlocks(0) after console_flush_on_panic(), let the console device drivers > > think the Oops is still in progress to call spin_trylock() instead of spin_lock() to > > avoid the deadlock. > > hm. Sergey, is this at all related to the UART printk deadlock change > which you're presently discussing in > http://lkml.kernel.org/r/20180615093919.559-1-sergey.senozhatsky@gmail.com?
Hi Andrew,
Not exactly. The change I'm discussing is a little different - it's about re-entrant UART [+ circular locking in TTY], when UART deadlocks us because of printk()-s issued by MM/tty/WQ/sched/other core kernel stuff/etc
Example: IRQ -> uart -> tty -> WQ -> printk -> uart
-ss
| |