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
| ||
|
Date: Mon, 4 Jun 2018 14:45:57 +0900 From: Hoeun Ryu <hoeun.ryu@....com.com> To: Andrew Morton <akpm@...ux-foundation.org>, 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> Cc: Hoeun Ryu <hoeun.ryu@....com>, linux-kernel@...r.kernel.org Subject: [PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks 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. Signed-off-by: Hoeun Ryu <hoeun.ryu@....com> --- kernel/panic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/panic.c b/kernel/panic.c index 42e4874..b4063b6 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -233,8 +233,6 @@ void panic(const char *fmt, ...) if (_crash_kexec_post_notifiers) __crash_kexec(NULL); - bust_spinlocks(0); - /* * We may have ended up stopping the CPU holding the lock (in * smp_send_stop()) while still having some valuable data in the console @@ -246,6 +244,8 @@ void panic(const char *fmt, ...) debug_locks_off(); console_flush_on_panic(); + bust_spinlocks(0); + if (!panic_blink) panic_blink = no_blink; -- 2.1.4
Powered by blists - more mailing lists