diff options
| author | Rabin Vincent <rabin@rab.in> | 2014-11-14 19:00:41 +0100 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2014-11-25 17:06:40 -0800 |
| commit | 6fad18fa51392c9847a4e3a95134b2e57155e563 (patch) | |
| tree | 9e3fbe4761771ea5658691462cc3b79749cd4836 | |
| parent | 3ffb1a8193bead7bf4ef0fec2dae050c70e4c1c1 (diff) | |
| download | linux-6fad18fa51392c9847a4e3a95134b2e57155e563.tar.gz linux-6fad18fa51392c9847a4e3a95134b2e57155e563.tar.bz2 linux-6fad18fa51392c9847a4e3a95134b2e57155e563.zip | |
serial: 8250: don't attempt a trylock if in sysrq
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
CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc4+ #37
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
ffffffff8245ba00 ffffffff81628b28 ffffffff812c8d27 ffffffff81628b48
ffffffff8106812e ffffffff8245ba00 ffffffff814e22ed ffffffff81628b68
ffffffff810681a6 0000000000000000 0000000000000000 ffffffff81628b88
Call Trace:
<IRQ> [<ffffffff812c8d27>] dump_stack+0x19/0x1b
[<ffffffff8106812e>] spin_dump+0x7e/0xd0
[<ffffffff810681a6>] spin_bug+0x26/0x30
[<ffffffff8106843c>] do_raw_spin_trylock+0x4c/0x60
[<ffffffff812cdb1d>] _raw_spin_trylock+0x1d/0x60
[<ffffffff812336d8>] serial8250_console_write+0x68/0x190
[<ffffffff811eb0b0>] ? sprintf+0x40/0x50
[<ffffffff8106ab5e>] call_console_drivers.constprop.11+0x9e/0xf0
[<ffffffff8106b276>] console_unlock+0x3e6/0x490
[<ffffffff8106b595>] vprintk_emit+0x275/0x530
[<ffffffff812c869a>] printk+0x4d/0x4f
[<ffffffff8121e612>] __handle_sysrq+0x62/0x1b0
[<ffffffff8121e5b5>] ? __handle_sysrq+0x5/0x1b0
[<ffffffff8121ebc6>] handle_sysrq+0x26/0x30
[<ffffffff81233157>] serial8250_rx_chars+0x1d7/0x250
[<ffffffff812338bb>] serial8250_handle_irq+0x7b/0x90
[<ffffffff812338f3>] serial8250_default_handle_irq+0x23/0x30
[<ffffffff812318b3>] serial8250_interrupt+0x63/0xe0
[<ffffffff8106d80e>] handle_irq_event_percpu+0x4e/0x200
[<ffffffff8106da01>] handle_irq_event+0x41/0x70
[<ffffffff810701ee>] ? handle_edge_irq+0x1e/0x110
[<ffffffff8107026e>] handle_edge_irq+0x9e/0x110
[<ffffffff810041c2>] handle_irq+0x22/0x40
[<ffffffff812d096e>] do_IRQ+0x4e/0xf0
[<ffffffff812cf4ed>] common_interrupt+0x6d/0x6d
<EOI> [<ffffffff8100acbf>] ? default_idle+0x1f/0xd0
[<ffffffff8100acbd>] ? default_idle+0x1d/0xd0
[<ffffffff8100b61f>] arch_cpu_idle+0xf/0x20
[<ffffffff8105c1db>] cpu_startup_entry+0x25b/0x360
[<ffffffff812c726e>] rest_init+0xbe/0xd0
[<ffffffff816a4dcb>] start_kernel+0x339/0x346
[<ffffffff816a4495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff816a4589>] x86_64_start_kernel+0xf2/0xf6
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.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| -rw-r--r-- | drivers/tty/serial/8250/8250_core.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index d0d0c3b6af02..9515924b7f38 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -3191,7 +3191,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); |