[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05280c37163d08ff2d00d71c5454baf651867bd3.camel@sipsolutions.net>
Date: Wed, 04 May 2022 11:24:24 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Tejun Heo <tj@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dmitry Vyukov <dvyukov@...gle.com>,
"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
Hillf Danton <hdanton@...a.com>,
syzbot <syzbot+c56f6371c48cad0420f9@...kaller.appspotmail.com>
Subject: Re: [syzbot] INFO: task hung in hci_dev_close_sync
On Wed, 2022-05-04 at 05:12 +0000, Tetsuo Handa wrote:
>
> This seems to be a question regarding commit 87915adc3f0acdf0 ("workqueue: re-add lockdep dependencies for flushing").
> >
> > syzbot should have been able to catch cancel_work_sync() in work context
> > by checking lockdep_map in __flush_work() for both flush and cancel.
> >
> > Hillf
> >
> > --- y/kernel/workqueue.c
> > +++ x/kernel/workqueue.c
> > @@ -3075,10 +3075,10 @@ static bool __flush_work(struct work_str
> > if (WARN_ON(!work->func))
> > return false;
> >
> > - if (!from_cancel) {
> > + //if (!from_cancel) {
> >
I think this is explained in commit d6e89786bed9 ("workqueue: skip
lockdep wq dependency in cancel_work_sync()")
johannes
Powered by blists - more mailing lists