* Nested calls to spin_lock_irq with different locks
@ 2022-11-19 15:17 Guenter Roeck
2022-11-20 1:26 ` Waiman Long
0 siblings, 1 reply; 2+ messages in thread
From: Guenter Roeck @ 2022-11-19 15:17 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long, Boqun Feng
Hi,
recently I have seen various syzbot reports reporting inconsistent lock
states. One example is
================================
WARNING: inconsistent lock state
5.16.0-syzkaller #0 Not tainted
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
syz-executor.2/18360 [HC0[0]:SC0[0]:HE0:SE1] takes:
ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: spin_lock_irq include/linux/spinlock.h:374 [inline]
ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: sync_info_debugfs_show+0x2d/0x200 drivers/dma-buf/sync_debug.c:147
{IN-HARDIRQ-W} state was registered at:
lock_acquire kernel/locking/lockdep.c:5639 [inline]
lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162
sync_timeline_debug_remove+0x25/0x190 drivers/dma-buf/sync_debug.c:31
================================
WARNING: inconsistent lock state
5.16.0-syzkaller #0 Not tainted
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
syz-executor.2/18360 [HC0[0]:SC0[0]:HE0:SE1] takes:
ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: spin_lock_irq include/linux/spinlock.h:374 [inline]
ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: sync_info_debugfs_show+0x2d/0x200 drivers/dma-buf/sync_debug.c:147
The log is from
https://lore.kernel.org/lkml/000000000000d5b3af05edc9d445@google.com/T/.
sync_info_debugfs_show() calls spin_lock_irq(&sync_timeline_list_lock).
With the lock active, it calls sync_print_obj(), which calls
spin_lock_irq(&obj->lock) and spin_unlock_irq(&obj->lock).
spin_unlock_irq(), via __raw_spin_unlock_irq(), calls local_irq_enable(),
presumably enabling hardware interrupts. If such a hardware interrupt
calls sync_timeline_debug_remove(), the problem would be seen.
Can this happen in practice ? In other words, does that mean that nested
calls to spin_lock_irq() (with different locks) are not supported ?
If that is indeed the case, is there a suggested remedy ?
Thanks,
Guenter
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Nested calls to spin_lock_irq with different locks
2022-11-19 15:17 Nested calls to spin_lock_irq with different locks Guenter Roeck
@ 2022-11-20 1:26 ` Waiman Long
0 siblings, 0 replies; 2+ messages in thread
From: Waiman Long @ 2022-11-20 1:26 UTC (permalink / raw)
To: Guenter Roeck, linux-kernel
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng
On 11/19/22 10:17, Guenter Roeck wrote:
> Hi,
>
> recently I have seen various syzbot reports reporting inconsistent lock
> states. One example is
>
> ================================
> WARNING: inconsistent lock state
> 5.16.0-syzkaller #0 Not tainted
> --------------------------------
> inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> syz-executor.2/18360 [HC0[0]:SC0[0]:HE0:SE1] takes:
> ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: spin_lock_irq include/linux/spinlock.h:374 [inline]
> ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: sync_info_debugfs_show+0x2d/0x200 drivers/dma-buf/sync_debug.c:147
> {IN-HARDIRQ-W} state was registered at:
> lock_acquire kernel/locking/lockdep.c:5639 [inline]
> lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162
> sync_timeline_debug_remove+0x25/0x190 drivers/dma-buf/sync_debug.c:31
>
> ================================
> WARNING: inconsistent lock state
> 5.16.0-syzkaller #0 Not tainted
> --------------------------------
> inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> syz-executor.2/18360 [HC0[0]:SC0[0]:HE0:SE1] takes:
> ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: spin_lock_irq include/linux/spinlock.h:374 [inline]
> ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: sync_info_debugfs_show+0x2d/0x200 drivers/dma-buf/sync_debug.c:147
>
> The log is from
> https://lore.kernel.org/lkml/000000000000d5b3af05edc9d445@google.com/T/.
>
> sync_info_debugfs_show() calls spin_lock_irq(&sync_timeline_list_lock).
> With the lock active, it calls sync_print_obj(), which calls
> spin_lock_irq(&obj->lock) and spin_unlock_irq(&obj->lock).
>
> spin_unlock_irq(), via __raw_spin_unlock_irq(), calls local_irq_enable(),
> presumably enabling hardware interrupts. If such a hardware interrupt
> calls sync_timeline_debug_remove(), the problem would be seen.
>
> Can this happen in practice ? In other words, does that mean that nested
> calls to spin_lock_irq() (with different locks) are not supported ?
> If that is indeed the case, is there a suggested remedy ?
That is what spin_lock_irqsave() and spin_unlock_irqrestore() are for.
If you are not certain if a function will be called with interrupt
enabled or disabled, you should always use the irqsave/irqrestore
variant to make sure the function will work in both cases.
Cheers,
Longman
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-11-20 1:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-19 15:17 Nested calls to spin_lock_irq with different locks Guenter Roeck
2022-11-20 1:26 ` Waiman Long
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).