[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f30d186c-2924-e708-cc08-e0b9a7f70ca4@gmail.com>
Date: Fri, 26 Jul 2024 12:00:01 +0300
From: Eli Billauer <eli.billauer@...il.com>
To: syzbot <syzbot+91dbdfecdd3287734d8e@...kaller.appspotmail.com>,
arnd@...db.de, gregkh@...uxfoundation.org, hdanton@...a.com,
johan.hedberg@...il.com, linux-bluetooth@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
luiz.dentz@...il.com, marcel@...tmann.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [bluetooth?] possible deadlock in touch_wq_lockdep_map
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
Powered by blists - more mailing lists