Re: [PATCH v2] usb: uas: quiesce SCSI before stopping endpoints on unbind

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb: uas: 30-second hang and 100% CPU livelock on physical unplug
--

commit fb8eab9b3967bb30e72e5cba65984f12ee6267cd
Author: Jiayi Li <lijiayi@kylinos.cn>

usb: uas: quiesce SCSI before stopping endpoints on unbind

This patch reorders the teardown sequence in uas_disconnect() to remove
the SCSI host and cancel scanning before setting the resetting flag and
killing anchored URBs. The goal is to quiesce SCSI before stopping endpoints
on unbind.

Link: https://lore.kernel.org/lkml/20260920012358.3362053-1-lijiayi@kylinos.cn/

> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
> index 2651629812694..971a9dc012e9b 100644
> --- a/drivers/usb/storage/uas.c
> +++ b/drivers/usb/storage/uas.c
> @@ -1217,6 +1217,14 @@ static void uas_disconnect(struct usb_interface *intf)
>  	struct uas_dev_info *devinfo = (struct uas_dev_info *)shost->hostdata;
>  	unsigned long flags;
>  
> +	/*
> +	 * Prevent SCSI scanning (if it hasn't started yet)
> +	 * or wait for the SCSI-scanning routine to stop.
> +	 */
> +	cancel_work_sync(&devinfo->scan_work);
> +
> +	scsi_remove_host(shost);
> +

[Severity: High]
Will moving scsi_remove_host() before devinfo->resetting = 1 and
uas_zap_pending() cause a 30-second hang and 100% CPU livelock on
physical unplug?

On physical unplug, usbcore detects the disconnect and calls
usb_disable_device(), which kills all active URBs with status -ESHUTDOWN
before calling uas_disconnect().

URB completion handlers like uas_stat_cmplt() handle -ESHUTDOWN by jumping
to bail, intentionally bypassing the clearing of the COMMAND_INFLIGHT flag
and leaving the SCSI commands stuck in-flight:

drivers/usb/storage/uas.c:uas_stat_cmplt() {
    ...
    if (status) {
        if (status != -ENOENT && status != -ECONNRESET && status != -ESHUTDOWN)
            dev_err(&urb->dev->dev, "stat urb: status %d\n", status);
        goto bail;
    }
    ...
}

scsi_remove_host() synchronously waits for all in-flight SCSI commands to
complete. Because the commands are stuck in-flight until uas_zap_pending()
forcefully completes them, scsi_remove_host() will block indefinitely.

During this hang, any commands in IS_IN_WORK_LIST repeatedly trigger
uas_do_work(). Since the device is detached, uas_submit_urbs() fails.
Because devinfo->resetting is still 0 at this point, the work is
unconditionally requeued:

drivers/usb/storage/uas.c:uas_do_work() {
    ...
    err = uas_submit_urbs(cmnd, cmnd->device->hostdata);
    if (!err)
        cmdinfo->state &= ~IS_IN_WORK_LIST;
    else
        queue_work(workqueue, &devinfo->work);
    ...
}

Will this cause the workqueue thread to livelock, burning 100% CPU for
30 seconds until the SCSI error handler timeout finally aborts the commands?

>  	spin_lock_irqsave(&devinfo->lock, flags);
>  	devinfo->resetting = 1;
>  	spin_unlock_irqrestore(&devinfo->lock, flags);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922031102.141043-1-lijiayi@kylinos.cn?part=1