[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <49e04fb8-e8fe-17d3-0b5f-e8d255010936@I-love.SAKURA.ne.jp>
Date: Thu, 28 Jul 2022 21:25:50 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Johannes Berg <johannes@...solutions.net>,
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 2022/05/04 18:24, Johannes Berg wrote:
> 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()")
I couldn't agree on that reasoning, and I sent
https://lkml.kernel.org/r/21b9c1ac-64b7-7f4b-1e62-bf2f021fffcd@I-love.SAKURA.ne.jp .
Powered by blists - more mailing lists