Re: [usb-storage] [PATCH v2] usb: storage: don't hold dev_mutex across the max_lun control transfer

[Alan Stern]

On Mon, Nov 09, 2026 at 07:53:07AM +0800, 'Shuai Liu' via USB Mass Storage on Linux wrote:
> usb_stor_scan_dwork() acquires us->dev_mutex and then calls
> usb_stor_Bulk_max_lun(), which issues a synchronous GET_MAX_LUN control
> transfer (10s timeout).  The reset and suspend callbacks
> (usb_stor_pre_reset / usb_stor_suspend) also acquire us->dev_mutex, but
> they run while the USB core already holds the device lock
> (udev->dev.mutex) during usb_reset_device() or disconnect.  This
> creates an AB-BA deadlock:
> 
>   scan work           reset/disconnect
>   ---------           ----------------
>   mutex_lock(dev_mutex)
>                       device_lock(udev)      [USB core]
>   control transfer  -- blocks waiting for
>                         the device lock

You lost me.  Exactly where does usb_stor_scan_dwork() or 
usb_stor_Bulk_max_lun() try to lock udev?  Taking that lock while 
holding us->dev_mutex certainly would be a violation of the locking 
order used by the rest of the driver.

>                       mutex_lock(dev_mutex)  [pre_reset]
>                         -- blocks forever
> 
> syzbot reports this as a task hung in usb_stor_scan_dwork(), with
> cancel_delayed_work_sync() in quiesce_and_remove_host() unable to make
> progress.

Are you certain this diagnosis is correct?  I can imagine the task being 
hung inside the mutex_lock(&us->dev_mutex) call, but that's not what you 
are claiming.

Alan Stern