Re: [syzbot] [comedi?] inconsistent lock state in das16m1_interrupt

[Ian Abbott]

On 2026-02-14 16:40, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    fd9678829d6d Add linux-next specific files for 20260210
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16c30e5a580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c09aefae2687abea
> dashboard link: https://syzkaller.appspot.com/bug?extid=cc9f7f4a7df09f53c4a4
> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ca4a117cc311/disk-fd967882.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/d6c5dc8e793f/vmlinux-fd967882.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/011094935f45/bzImage-fd967882.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+cc9f7f4a7df09f53c4a4@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> ================================
> WARNING: inconsistent lock state
> syzkaller #0 Not tainted
> --------------------------------
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> syz.0.15721/11171 [HC1[1]:SC0[0]:HE0:SE1] takes:
> ffff888031648868 (&dev->spinlock){?...}-{3:3}, at: spin_lock include/linux/spinlock.h:341 [inline]
> ffff888031648868 (&dev->spinlock){?...}-{3:3}, at: das16m1_interrupt+0x5e/0x180 drivers/comedi/drivers/das16m1.c:460
> {HARDIRQ-ON-W} state was registered at:
>    lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
>    __raw_spin_lock_bh include/linux/spinlock_api_smp.h:150 [inline]
>    _raw_spin_lock_bh+0x36/0x50 kernel/locking/spinlock.c:178
>    spin_lock_bh include/linux/spinlock.h:347 [inline]
>    waveform_ao_cancel+0x8d/0x120 drivers/comedi/drivers/comedi_test.c:628
>    do_cancel drivers/comedi/comedi_fops.c:818 [inline]
>    comedi_close+0x27e/0x5e0 drivers/comedi/comedi_fops.c:3036
>    __fput+0x44f/0xa70 fs/file_table.c:469
>    task_work_run+0x1d9/0x270 kernel/task_work.c:233
>    resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
>    __exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
>    exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98
>    __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
>    syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
>    syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
>    do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
> irq event stamp: 1472
> hardirqs last  enabled at (1471): [<ffffffff8bad7f2e>] irqentry_exit+0x59e/0x620 kernel/entry/common.c:242
> hardirqs last disabled at (1472): [<ffffffff8bad3763>] common_interrupt+0x13/0xe0 arch/x86/kernel/irq.c:326
> softirqs last  enabled at (1404): [<ffffffff81880def>] __do_softirq kernel/softirq.c:660 [inline]
> softirqs last  enabled at (1404): [<ffffffff81880def>] invoke_softirq kernel/softirq.c:496 [inline]
> softirqs last  enabled at (1404): [<ffffffff81880def>] __irq_exit_rcu+0x5f/0x150 kernel/softirq.c:727
> softirqs last disabled at (1275): [<ffffffff81880def>] __do_softirq kernel/softirq.c:660 [inline]
> softirqs last disabled at (1275): [<ffffffff81880def>] invoke_softirq kernel/softirq.c:496 [inline]
> softirqs last disabled at (1275): [<ffffffff81880def>] __irq_exit_rcu+0x5f/0x150 kernel/softirq.c:727
>
> other info that might help us debug this:
>   Possible unsafe locking scenario:
>
>         CPU0
>         ----
>    lock(&dev->spinlock);
>    <Interrupt>
>      lock(&dev->spinlock);
>
>   *** DEADLOCK ***

The use of the same instance of the spin-lock (member `spinlock` in an 
instance of a `struct comedi_device`) in both 
"drivers/comedi/drivers/comedi_test.c" and 
"drivers/comedi/drivers/das16m1.c" suggests the COMEDI device instance 
was first attached to the "comedi_test" low-level driver, and later 
detached, then attached to the "das16m1" low-level driver.  The COMEDI 
core initializes the spin-lock once, but it is for private use of the 
low-level driver.  Although the lock state should be consistent while it 
is in use by a single low-level driver, it is not necessarily consistent 
across different low-level drivers.  It should only be a problem as far 
as lock dependency checking it concerned, not a problem with actual 
deadlocks.

A possible fix is to reinitialize the spin-lock before attaching it to a 
new low-level driver (before the call to `driv->attach(dev, it)` from 
`comedi_device_attach()` in "drivers/comedi/drivers.c").  That appears 
to be allowable as long as the lock is not being held.  I guess it would 
reinitialize the lockdep tracking for the lock.

--
-=( Ian Abbott <abbotti@xxxxxxxxx> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-