On (06/20/18 14:30), Andrew Morton wrote:
> > From: Hoeun Ryu <hoeun....@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.senozhat...@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
