linux-kernel - Re: [PATCH] panic: move bust_spinlocks(0) after console_flush_on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 21 Jun 2018 10:23:23 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Hoeun Ryu <hoeun.ryu@....com.com>,
        Kees Cook <keescook@...omium.org>,
        Borislav Petkov <bp@...e.de>, Andi Kleen <ak@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Hoeun Ryu <hoeun.ryu@....com>, linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Petr Mladek <pmladek@...e.com>
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@....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