lkml.org 
[lkml]   [2018]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks
On Mon,  4 Jun 2018 14:45:57 +0900
Hoeun Ryu <hoeun.ryu@lge.com.com> 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.
>
> Signed-off-by: Hoeun Ryu <hoeun.ryu@lge.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);

Added a few more to Cc. This looks like it could have subtle
side-effects. I'd like those that have been touching the code around
here to have a look.

-- Steve


> +
> if (!panic_blink)
> panic_blink = no_blink;
>

\
 
 \ /
  Last update: 2018-06-05 03:44    [W:0.066 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site