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

[Shuai Liu]

On Sun, Nov 08, 2026 at 09:10:50PM -0500, Alan Stern wrote:
> 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.
>
> You are 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.

You are right, and I am sorry for the confusion.  My analysis was wrong
and this patch cannot fix the reported hang.

I went back to the full report and read the "locks held" section, which
makes the picture unambiguous:

 - the hung kworker is blocked in mutex_lock(&us->dev_mutex) at the very
   entry of usb_stor_scan_dwork(), so it never reaches
   usb_stor_Bulk_max_lun();
 - that mutex is owned by a usb_hub_wq worker sitting in
   ene_ub6250_probe() (ene_ub6250.c:2363), which holds it while
   ene_get_card_type() -> ene_send_scsi_cmd() ->
   usb_stor_bulk_transfer_buf() waits for a bulk transfer;
 - the wait goes through usb_stor_msg_common(us, 0), i.e. with
   MAX_SCHEDULE_TIMEOUT and no timeout at all.  That is fine for a
   transfer belonging to a SCSI command, whose timeout and abort
   handling end the wait, but a card-type query has no SCSI command
   behind it, so a device which enumerates but never services bulk
   transfers blocks the probe forever;
 - the same probe path also holds udev->dev.mutex, which is why
   usbdev_open() is blocked in the report.

So the deadlock I described does not exist; the scan work is a victim,
not a participant.  Taking the transfer out of the dev_mutex critical
section leaves the mutex_lock() in place, so the hang would remain.

Please drop this patch.

The right fix is already on the list: Hongyu Xie's

  [PATCH v4] usb-storage: ene_ub6250: don't let the card-type probe hang forever
  https://lore.kernel.org/all/20261109085449.83117-1-xiehongyu1@xxxxxxxxxx/

which bounds the whole card-type query with a time budget.  That is the
correct place to address this.

Sorry for the noise.

Shuai Liu