* lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8 @ 2020-08-11 10:13 Will Deacon 2020-08-11 10:38 ` peterz 0 siblings, 1 reply; 4+ messages in thread From: Will Deacon @ 2020-08-11 10:13 UTC (permalink / raw) To: linux, gregkh, andre.przywara; +Cc: peterz, linux-kernel, linux-arm-kernel Hi, Using magic-sysrq via a keyboard interrupt over the serial console results in the following lockdep splat with the PL011 UART driver on v5.8. I can reproduce the issue under QEMU with arm64 defconfig + PROVE_LOCKING. Any chance somebody could take a look, please? It's a little annoying, because it means when I uses magic-sysrq to increase the loglevel prior to testing something else, lockdep gets disabled as a result. Cheers, Will --->8 [ 56.377562] sysrq: Changing Loglevel [ 56.385777] sysrq: Loglevel set to 9 [ 56.387291] [ 56.387378] ====================================================== [ 56.387391] WARNING: possible circular locking dependency detected [ 56.387401] 5.8.0 #2 Not tainted [ 56.387411] ------------------------------------------------------ [ 56.387421] swapper/0/0 is trying to acquire lock: [ 56.387467] ffffb190db294ab0 (console_owner){-.-.}-{0:0}, at: console_lock_spinning_enable+0x34/0x70 [ 56.387525] [ 56.387535] but task is already holding lock: [ 56.387544] ffff0000fe512898 (&port_lock_key){-.-.}-{2:2}, at: pl011_int+0x40/0x488 [ 56.387582] [ 56.387592] which lock already depends on the new lock. [ 56.387600] [ 56.387608] [ 56.387618] the existing dependency chain (in reverse order) is: [ 56.387626] [ 56.387633] -> #1 (&port_lock_key){-.-.}-{2:2}: [ 56.387671] lock_acquire+0xc8/0x2a0 [ 56.387680] _raw_spin_lock+0x6c/0x84 [ 56.387690] pl011_console_write+0x88/0x1e0 [ 56.387699] console_unlock+0x2f4/0x544 [ 56.387708] vprintk_emit+0x130/0x1c4 [ 56.387717] vprintk_default+0x4c/0x74 [ 56.387726] vprintk_func+0x1fc/0x204 [ 56.387735] printk+0x5c/0x84 [ 56.387744] register_console+0x340/0x38c [ 56.387754] uart_add_one_port+0x4b0/0x590 [ 56.387763] pl011_register_port+0x98/0xd4 [ 56.387772] sbsa_uart_probe+0x240/0x294 [ 56.387781] platform_drv_probe+0x98/0xc0 [ 56.387791] really_probe+0x1b8/0x430 [ 56.387800] driver_probe_device+0x80/0xbc [ 56.387809] __device_attach_driver+0x100/0x11c [ 56.387821] bus_for_each_drv+0x84/0xd0 [ 56.387830] __device_attach+0xc4/0x168 [ 56.387840] device_initial_probe+0x18/0x24 [ 56.387849] bus_probe_device+0x38/0xa0 [ 56.387858] device_add+0x8f8/0xa10 [ 56.387868] platform_device_add+0x88/0x228 [ 56.387878] platform_device_register_full+0x13c/0x180 [ 56.387888] acpi_create_platform_device+0x1f4/0x254 [ 56.387897] acpi_bus_attach+0x284/0x2cc [ 56.387906] acpi_bus_attach+0xcc/0x2cc [ 56.387916] acpi_bus_attach+0xcc/0x2cc [ 56.387925] acpi_bus_scan+0x4c/0xac [ 56.387934] acpi_scan_init+0xc0/0x24c [ 56.387943] acpi_init+0xa4/0xbc [ 56.387952] do_one_initcall+0x9c/0x17c [ 56.387961] do_initcall_level+0x9c/0xb8 [ 56.387971] do_initcalls+0x54/0x94 [ 56.387980] do_basic_setup+0x24/0x30 [ 56.387989] kernel_init_freeable+0x158/0x1b0 [ 56.387998] kernel_init+0x18/0x190 [ 56.388007] ret_from_fork+0x10/0x30 [ 56.388015] [ 56.388023] -> #0 (console_owner){-.-.}-{0:0}: [ 56.388060] validate_chain+0x658/0x2918 [ 56.388069] __lock_acquire+0xb4c/0xf98 [ 56.388078] lock_acquire+0xc8/0x2a0 [ 56.388088] console_lock_spinning_enable+0x60/0x70 [ 56.388097] console_unlock+0x2ac/0x544 [ 56.388106] vprintk_emit+0x130/0x1c4 [ 56.388115] vprintk_default+0x4c/0x74 [ 56.388124] vprintk_func+0x1fc/0x204 [ 56.388133] printk+0x5c/0x84 [ 56.388142] __handle_sysrq+0x180/0x200 [ 56.388151] handle_sysrq+0x30/0x3c [ 56.388160] pl011_fifo_to_tty+0xf4/0x200 [ 56.388170] pl011_int+0x204/0x488 [ 56.388179] __handle_irq_event_percpu+0xac/0x1a0 [ 56.388188] handle_irq_event+0x64/0x150 [ 56.388198] handle_fasteoi_irq+0xf8/0x1cc [ 56.388207] __handle_domain_irq+0x8c/0xd0 [ 56.388216] gic_handle_irq+0xc8/0x168 [ 56.388225] el1_irq+0xbc/0x180 [ 56.388234] arch_cpu_idle+0x3c/0x5c [ 56.388243] do_idle+0x104/0x2b0 [ 56.388253] cpu_startup_entry+0x28/0x2c [ 56.388262] rest_init+0x1f4/0x208 [ 56.388271] arch_call_rest_init+0x10/0x1c [ 56.388280] start_kernel+0x3a4/0x420 [ 56.388288] [ 56.388298] other info that might help us debug this: [ 56.388305] [ 56.388315] Possible unsafe locking scenario: [ 56.388322] [ 56.388332] CPU0 CPU1 [ 56.388341] ---- ---- [ 56.388349] lock(&port_lock_key); [ 56.388373] lock(console_owner); [ 56.388396] lock(&port_lock_key); [ 56.388418] lock(console_owner); [ 56.388440] [ 56.388448] *** DEADLOCK *** [ 56.388456] [ 56.388465] 3 locks held by swapper/0/0: [ 56.388473] #0: ffff0000fe512898 (&port_lock_key){-.-.}-{2:2}, at: pl011_int+0x40/0x488 [ 56.388516] #1: ffffb190db297770 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x0/0x40 [ 56.388559] #2: ffffb190db294990 (console_lock){+.+.}-{0:0}, at: vprintk_emit+0x128/0x1c4 [ 56.388602] [ 56.388611] stack backtrace: [ 56.388621] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0 #2 [ 56.388632] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ 56.388640] Call trace: [ 56.388649] dump_backtrace+0x0/0x1d8 [ 56.388658] show_stack+0x1c/0x28 [ 56.388667] dump_stack+0xe4/0x190 [ 56.388676] print_circular_bug+0x5dc/0x610 [ 56.388685] check_noncircular+0x1a8/0x1b0 [ 56.388694] validate_chain+0x658/0x2918 [ 56.388703] __lock_acquire+0xb4c/0xf98 [ 56.388712] lock_acquire+0xc8/0x2a0 [ 56.388721] console_lock_spinning_enable+0x60/0x70 [ 56.388730] console_unlock+0x2ac/0x544 [ 56.388739] vprintk_emit+0x130/0x1c4 [ 56.388748] vprintk_default+0x4c/0x74 [ 56.388757] vprintk_func+0x1fc/0x204 [ 56.388766] printk+0x5c/0x84 [ 56.388776] __handle_sysrq+0x180/0x200 [ 56.388787] handle_sysrq+0x30/0x3c [ 56.388796] pl011_fifo_to_tty+0xf4/0x200 [ 56.388805] pl011_int+0x204/0x488 [ 56.388815] __handle_irq_event_percpu+0xac/0x1a0 [ 56.388824] handle_irq_event+0x64/0x150 [ 56.388834] handle_fasteoi_irq+0xf8/0x1cc [ 56.388843] __handle_domain_irq+0x8c/0xd0 [ 56.388852] gic_handle_irq+0xc8/0x168 [ 56.388861] el1_irq+0xbc/0x180 [ 56.388870] arch_cpu_idle+0x3c/0x5c [ 56.388880] do_idle+0x104/0x2b0 [ 56.388889] cpu_startup_entry+0x28/0x2c [ 56.388898] rest_init+0x1f4/0x208 [ 56.388907] arch_call_rest_init+0x10/0x1c [ 56.388917] start_kernel+0x3a4/0x420 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8 2020-08-11 10:13 lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8 Will Deacon @ 2020-08-11 10:38 ` peterz 2020-08-11 11:17 ` Will Deacon 0 siblings, 1 reply; 4+ messages in thread From: peterz @ 2020-08-11 10:38 UTC (permalink / raw) To: Will Deacon; +Cc: gregkh, linux-kernel, linux, linux-arm-kernel, andre.przywara On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote: > Hi, > > Using magic-sysrq via a keyboard interrupt over the serial console results in > the following lockdep splat with the PL011 UART driver on v5.8. I can reproduce > the issue under QEMU with arm64 defconfig + PROVE_LOCKING. > > Any chance somebody could take a look, please? It's a little annoying, > because it means when I uses magic-sysrq to increase the loglevel prior > to testing something else, lockdep gets disabled as a result. > Going by msm_serial, the thing to do is something like this: diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index 8efd7c2a34fe..1717790ece2b 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -308,8 +308,9 @@ static void pl011_write(unsigned int val, const struct uart_amba_port *uap, */ static int pl011_fifo_to_tty(struct uart_amba_port *uap) { - u16 status; unsigned int ch, flag, fifotaken; + int sysrq; + u16 status; for (fifotaken = 0; fifotaken != 256; fifotaken++) { status = pl011_read(uap, REG_FR); @@ -344,10 +345,12 @@ static int pl011_fifo_to_tty(struct uart_amba_port *uap) flag = TTY_FRAME; } - if (uart_handle_sysrq_char(&uap->port, ch & 255)) - continue; + spin_unlock(&uap->port.lock); + sysrq = uart_handle_sysrq_char(&uap->port, ch & 255); + spin_lock(&uap->port.lock); - uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag); + if (!sysrq) + uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag); } return fifotaken; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8 2020-08-11 10:38 ` peterz @ 2020-08-11 11:17 ` Will Deacon 2020-08-11 12:36 ` Will Deacon 0 siblings, 1 reply; 4+ messages in thread From: Will Deacon @ 2020-08-11 11:17 UTC (permalink / raw) To: peterz; +Cc: gregkh, linux-kernel, linux, linux-arm-kernel, andre.przywara On Tue, Aug 11, 2020 at 12:38:41PM +0200, peterz@infradead.org wrote: > On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote: > > Using magic-sysrq via a keyboard interrupt over the serial console results in > > the following lockdep splat with the PL011 UART driver on v5.8. I can reproduce > > the issue under QEMU with arm64 defconfig + PROVE_LOCKING. > > > > Any chance somebody could take a look, please? It's a little annoying, > > because it means when I uses magic-sysrq to increase the loglevel prior > > to testing something else, lockdep gets disabled as a result. > > > > Going by msm_serial, the thing to do is something like this: > > diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c > index 8efd7c2a34fe..1717790ece2b 100644 > --- a/drivers/tty/serial/amba-pl011.c > +++ b/drivers/tty/serial/amba-pl011.c > @@ -308,8 +308,9 @@ static void pl011_write(unsigned int val, const struct uart_amba_port *uap, > */ > static int pl011_fifo_to_tty(struct uart_amba_port *uap) > { > - u16 status; > unsigned int ch, flag, fifotaken; > + int sysrq; > + u16 status; > > for (fifotaken = 0; fifotaken != 256; fifotaken++) { > status = pl011_read(uap, REG_FR); > @@ -344,10 +345,12 @@ static int pl011_fifo_to_tty(struct uart_amba_port *uap) > flag = TTY_FRAME; > } > > - if (uart_handle_sysrq_char(&uap->port, ch & 255)) > - continue; > + spin_unlock(&uap->port.lock); > + sysrq = uart_handle_sysrq_char(&uap->port, ch & 255); > + spin_lock(&uap->port.lock); > > - uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag); > + if (!sysrq) > + uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag); > } > > return fifotaken; Cheers, that seems to do the trick: Tested-by: Will Deacon <will@kernel.org> but what I don't understand is why I haven't run into this before, and why nobody else seems to be reporting it! I'll try some older kernels to see if it ever worked. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8 2020-08-11 11:17 ` Will Deacon @ 2020-08-11 12:36 ` Will Deacon 0 siblings, 0 replies; 4+ messages in thread From: Will Deacon @ 2020-08-11 12:36 UTC (permalink / raw) To: peterz; +Cc: gregkh, linux-kernel, linux, linux-arm-kernel, andre.przywara On Tue, Aug 11, 2020 at 12:17:13PM +0100, Will Deacon wrote: > On Tue, Aug 11, 2020 at 12:38:41PM +0200, peterz@infradead.org wrote: > > diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c > > index 8efd7c2a34fe..1717790ece2b 100644 > > --- a/drivers/tty/serial/amba-pl011.c > > +++ b/drivers/tty/serial/amba-pl011.c > > @@ -308,8 +308,9 @@ static void pl011_write(unsigned int val, const struct uart_amba_port *uap, > > */ > > static int pl011_fifo_to_tty(struct uart_amba_port *uap) > > { > > - u16 status; > > unsigned int ch, flag, fifotaken; > > + int sysrq; > > + u16 status; > > > > for (fifotaken = 0; fifotaken != 256; fifotaken++) { > > status = pl011_read(uap, REG_FR); > > @@ -344,10 +345,12 @@ static int pl011_fifo_to_tty(struct uart_amba_port *uap) > > flag = TTY_FRAME; > > } > > > > - if (uart_handle_sysrq_char(&uap->port, ch & 255)) > > - continue; > > + spin_unlock(&uap->port.lock); > > + sysrq = uart_handle_sysrq_char(&uap->port, ch & 255); > > + spin_lock(&uap->port.lock); > > > > - uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag); > > + if (!sysrq) > > + uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag); > > } > > > > return fifotaken; > > Cheers, that seems to do the trick: > > Tested-by: Will Deacon <will@kernel.org> > > but what I don't understand is why I haven't run into this before, and why > nobody else seems to be reporting it! > > I'll try some older kernels to see if it ever worked. I tried 5.4, 4.19, 4.14 and 4.9: 5.4 and 4.19 have the lockdep splat 4.14 doesn't have the splat, yet I don't see why (the driver code hasn't really changed) 4.9 magic sysrq doesn't work at all (no splat either though) Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-08-11 12:38 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-11 10:13 lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8 Will Deacon 2020-08-11 10:38 ` peterz 2020-08-11 11:17 ` Will Deacon 2020-08-11 12:36 ` Will Deacon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).