Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161640AbaKNSba (ORCPT ); Fri, 14 Nov 2014 13:31:30 -0500 Received: from www.linutronix.de ([62.245.132.108]:54566 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161463AbaKNSb2 (ORCPT ); Fri, 14 Nov 2014 13:31:28 -0500 Message-ID: <54664A7C.5030404@linutronix.de> Date: Fri, 14 Nov 2014 19:31:24 +0100 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Rabin Vincent , Greg Kroah-Hartman CC: Ingo Molnar , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH] serial: 8250: don't attempt a trylock if in sysrq References: <1415988041-6124-1-git-send-email-rabin@rab.in> In-Reply-To: <1415988041-6124-1-git-send-email-rabin@rab.in> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/14/2014 07:00 PM, Rabin Vincent wrote: > Attempting to use SysRq via the 8250 serial port with spin lock > debugging on on a uniprocessor system results in the following splat: > > SysRq : > BUG: spinlock trylock failure on UP on CPU#0, swapper/0 > lock: serial8250_ports+0x0/0x8c0, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 > Call Trace: > [] dump_stack+0x19/0x1b > [] spin_dump+0x7e/0xd0 > [] spin_bug+0x26/0x30 > [] do_raw_spin_trylock+0x4c/0x60 > [] _raw_spin_trylock+0x1d/0x60 > [] serial8250_console_write+0x68/0x190 > [] ? sprintf+0x40/0x50 > [] call_console_drivers.constprop.11+0x9e/0xf0 > [] console_unlock+0x3e6/0x490 > [] vprintk_emit+0x275/0x530 > [] printk+0x4d/0x4f > [] __handle_sysrq+0x62/0x1b0 > [] handle_sysrq+0x26/0x30 > [] serial8250_rx_chars+0x1d7/0x250 > [] serial8250_handle_irq+0x7b/0x90 > [] serial8250_default_handle_irq+0x23/0x30 > [] serial8250_interrupt+0x63/0xe0 > [] handle_irq_event_percpu+0x4e/0x200 > HELP : loglevel(0-9) reboot(b) crash(c) show-all-locks(d) te... > > Before ebade5e833eda30 ("serial: 8250: Clean up the locking for -rt") > this was handled by not even attempting to try the lock if port->sysrq, > since it is known to be taken by the interrupt handler; see > https://bugzilla.kernel.org/show_bug.cgi?id=6716#c1. Restore that > behavior. Given the callchain it is expected that the lock is already taken. While this splat is easy to trigger in the sysrq way you might get the same splat in the oops_in_progress case which would be still okay. While this is harmless to apply, I wonder if it is worth the effort to teach lockdep that in this case it would be okay if the try_lock fails. > Signed-off-by: Rabin Vincent > --- > drivers/tty/serial/8250/8250_core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c > index ca5cfdc..aec51eb 100644 > --- a/drivers/tty/serial/8250/8250_core.c > +++ b/drivers/tty/serial/8250/8250_core.c > @@ -3198,7 +3198,9 @@ serial8250_console_write(struct console *co, const char *s, unsigned int count) > > serial8250_rpm_get(up); > > - if (port->sysrq || oops_in_progress) > + if (port->sysrq) > + locked = 0; > + else if (oops_in_progress) > locked = spin_trylock_irqsave(&port->lock, flags); > else > spin_lock_irqsave(&port->lock, flags); > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/