[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f47f6972-b977-aae8-dd4d-44d85db2e8a4@suse.com>
Date: Thu, 9 Dec 2021 14:21:20 +0100
From: Oliver Neukum <oneukum@...e.com>
To: Benjamin Berg <bberg@...hat.com>, Oliver Neukum <oneukum@...e.com>,
syzbot <syzbot+485cc00ea7cf41dfdbf1@...kaller.appspotmail.com>,
Thinh.Nguyen@...opsys.com, changbin.du@...el.com,
christian.brauner@...ntu.com, davem@...emloft.net,
edumazet@...gle.com, gregkh@...uxfoundation.org,
johan.hedberg@...il.com, kuba@...nel.org,
linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, luiz.dentz@...il.com,
luiz.von.dentz@...el.com, marcel@...tmann.org,
mathias.nyman@...ux.intel.com, netdev@...r.kernel.org,
stern@...land.harvard.edu, syzkaller-bugs@...glegroups.com,
yajun.deng@...ux.dev
Subject: Re: [syzbot] BUG: sleeping function called from invalid context in
hci_cmd_sync_cancel
On 09.12.21 13:46, Benjamin Berg wrote:
Hi,
> On Thu, 2021-12-09 at 11:06 +0100, Oliver Neukum wrote:
>> As __cancel_work_timer can be called from hci_cmd_sync_cancel() this is
>> just not
>> an approach you can take. It looks like asynchronously canceling the
>> scheduled work
>> would result in a race, so I would for now just revert.
> Right, so this needs to be pushed into a workqueue instead, I suppose.
It looks like overkill, but I have no good alternative to offer either.
>
>> What issue exactly is this trying to fix or improve?
> The problem is aborting long-running synchronous operations. i.e.
> without this patchset, USB enumeration will hang for 10s if a USB
> bluetooth device disappears during firmware loading. This is because
> even though the USB device is gone and all URB submissions fail, the
> operation will only be aborted after the internal timeout happens.
>
I see. Something ought to be done. The issue is in good hands.
Thanks
Oliver
Powered by blists - more mailing lists