[syzbot] [usb?] possible deadlock in __flush_workqueue (2)

[syzbot <syzbot+e528c9aad0fb5383ec83@syzkaller.appspotmail.com>]

Hello,

syzbot found the following issue on:

HEAD commit:    b446a2dae984 Merge tag 'linux_kselftest-fixes-6.11-rc3' of..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1253e123980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e8a2eef9745ade09
dashboard link: https://syzkaller.appspot.com/bug?extid=e528c9aad0fb5383ec83
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12a6bd23980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10b175e3980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/dfb1bb3422ba/disk-b446a2da.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/af839611c6d9/vmlinux-b446a2da.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b99bed56482e/bzImage-b446a2da.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e528c9aad0fb5383ec83@syzkaller.appspotmail.com

============================================
WARNING: possible recursive locking detected
6.11.0-rc2-syzkaller-00004-gb446a2dae984 #0 Not tainted
--------------------------------------------
kworker/0:1H/58 is trying to acquire lock:
ffff88802c60a148 ((wq_completion)xillyusb){+.+.}-{0:0}, at: touch_wq_lockdep_map kernel/workqueue.c:3876 [inline]
ffff88802c60a148 ((wq_completion)xillyusb){+.+.}-{0:0}, at: __flush_workqueue+0x1b0/0x1710 kernel/workqueue.c:3918

but task is already holding lock:
ffff88802c60a148 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3206 [inline]
ffff88802c60a148 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_scheduled_works+0x90a/0x1830 kernel/workqueue.c:3312

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock((wq_completion)xillyusb);
  lock((wq_completion)xillyusb);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by kworker/0:1H/58:
 #0: ffff88802c60a148 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3206 [inline]
 #0: ffff88802c60a148 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_scheduled_works+0x90a/0x1830 kernel/workqueue.c:3312
 #1: ffffc9000133fd00 ((work_completion)(&xdev->wakeup_workitem)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3207 [inline]
 #1: ffffc9000133fd00 ((work_completion)(&xdev->wakeup_workitem)){+.+.}-{0:0}, at: process_scheduled_works+0x945/0x1830 kernel/workqueue.c:3312

stack backtrace:
CPU: 0 UID: 0 PID: 58 Comm: kworker/0:1H Not tainted 6.11.0-rc2-syzkaller-00004-gb446a2dae984 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Workqueue: xillyusb wakeup_all
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 check_deadlock kernel/locking/lockdep.c:3061 [inline]
 validate_chain+0x15d3/0x5900 kernel/locking/lockdep.c:3855
 __lock_acquire+0x137a/0x2040 kernel/locking/lockdep.c:5142
 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759
 touch_wq_lockdep_map kernel/workqueue.c:3876 [inline]
 __flush_workqueue+0x1c9/0x1710 kernel/workqueue.c:3918
 drain_workqueue+0xc9/0x3a0 kernel/workqueue.c:4082
 destroy_workqueue+0xba/0xc40 kernel/workqueue.c:5781
 cleanup_dev drivers/char/xillybus/xillyusb.c:558 [inline]
 kref_put+0x104/0x180 include/linux/kref.h:65
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup