Re: [syzbot] [bluetooth?] possible deadlock in touch_wq_lockdep_map

Re: [syzbot] [bluetooth?] possible deadlock in touch_wq_lockdep_map

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    933069701c1b Merge tag '6.11-rc-smb3-server-fixes' of git:..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=10fba1f1980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f828342678294017
dashboard link: https://syzkaller.appspot.com/bug?extid=91dbdfecdd3287734d8e
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14f45af1980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14e8b645980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/22dd51445d03/disk-93306970.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f85f111961d5/vmlinux-93306970.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7971b4814e87/bzImage-93306970.xz

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

============================================
WARNING: possible recursive locking detected
6.10.0-syzkaller-g933069701c1b #0 Not tainted
--------------------------------------------
kworker/1:1H/1247 is trying to acquire lock:
ffff888121075948 ((wq_completion)xillyusb){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x6e/0x120 kernel/workqueue.c:3876

but task is already holding lock:
ffff888121075948 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_one_work+0x1277/0x1b40 kernel/workqueue.c:3206

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/1:1H/1247:
 #0: ffff888121075948 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_one_work+0x1277/0x1b40 kernel/workqueue.c:3206
 #1: ffffc900023afd80 ((work_completion)(&xdev->wakeup_workitem)){+.+.}-{0:0}, at: process_one_work+0x921/0x1b40 kernel/workqueue.c:3207

stack backtrace:
CPU: 1 UID: 0 PID: 1247 Comm: kworker/1:1H Not tainted 6.10.0-syzkaller-g933069701c1b #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+0x116/0x1f0 lib/dump_stack.c:119
 check_deadlock kernel/locking/lockdep.c:3061 [inline]
 validate_chain kernel/locking/lockdep.c:3855 [inline]
 __lock_acquire+0x2167/0x3cb0 kernel/locking/lockdep.c:5142
 lock_acquire kernel/locking/lockdep.c:5759 [inline]
 lock_acquire+0x1b1/0x560 kernel/locking/lockdep.c:5724
 touch_wq_lockdep_map+0x78/0x120 kernel/workqueue.c:3876
 __flush_workqueue+0x129/0x1200 kernel/workqueue.c:3918
 drain_workqueue+0x18f/0x3d0 kernel/workqueue.c:4082
 destroy_workqueue+0xc2/0xaa0 kernel/workqueue.c:5781
 cleanup_dev+0xc5/0x150 drivers/char/xillybus/xillyusb.c:558
 kref_put include/linux/kref.h:65 [inline]
 wakeup_all+0x28c/0x300 drivers/char/xillybus/xillyusb.c:612
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xf20 kernel/workqueue.c:3390
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 </TASK>


---
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.

Re: [syzbot] [bluetooth?] possible deadlock in touch_wq_lockdep_map

[Eli Billauer]

On 26/07/2024 6:20, syzbot wrote:
> WARNING: possible recursive locking detected
> 6.10.0-syzkaller-g933069701c1b #0 Not tainted
> --------------------------------------------
> kworker/1:1H/1247 is trying to acquire lock:
> ffff888121075948 ((wq_completion)xillyusb){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x6e/0x120 kernel/workqueue.c:3876
> 
> but task is already holding lock:
> ffff888121075948 ((wq_completion)xillyusb){+.+.}-{0:0}, at: process_one_work+0x1277/0x1b40 kernel/workqueue.c:3206

This is caused by xillyusb.c: destroy_workqueue() is (potentially) 
called from within a work item function, wakeup_all(). So the work item 
may attempt to destroy the work queue it sits on.

This bug has sneaked through the hardware tests as well as XillyUSB's 
users for several years, as its scenario is extremely unlikely in real 
life. It's nevertheless a bug to be fixed -- I'll submit a patch for this.

Thanks,
   Eli