Re: [PATCH] usb: storage: bound timeout=0 URB waits to 30s

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb-storage: hardcoded 30s URB timeout breaks long-running SCSI commands
--

commit e1a1498b59035fae65ddf1b4b34a943e9c28791c
Author: Hongyu Xie <xiehongyu1@kylinos.cn>

usb: storage: bound timeout=0 URB waits to 30s

This commit bounds timeout=0 URB waits in usb_stor_msg_common() to 30 seconds
to prevent permanent hangs when a device stops responding mid-transfer. It
replaces MAX_SCHEDULE_TIMEOUT with a 30-second timeout, matching the SCSI
layer's default command timeout for disk and CD-ROM LUs.

> diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
> index 8de3015bce050..a6588e55312c2 100644
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c

[ ... ]

> @@ -164,7 +173,7 @@ static int usb_stor_msg_common(struct us_data *us, int timeout)
>   
>  	/* wait for the completion of the URB */
>  	timeleft = wait_for_completion_interruptible_timeout(
> -			&urb_done, timeout ? : MAX_SCHEDULE_TIMEOUT);
> +			&urb_done, timeout ? : USB_STOR_URB_TIMEOUT);

[Severity: High]
Does this hardcoded 30-second timeout break legitimate long-running SCSI
commands like FORMAT UNIT or tape rewinds?

This logic unconditionally truncates unbounded transport waits to 30 seconds,
ignoring dynamic timeouts present in us->srb->request->timeout. A BOT SCSI
command taking longer than 30 seconds could legitimately withhold the CSW
until the operation finishes.

Could this cause usb_stor_msg_common() to kill the URB and return
USB_STOR_XFER_ERROR before the SCSI layer's own command timeout (which could
be hours) expires?

>   
>  	clear_bit(US_FLIDX_URB_ACTIVE, &us->dflags);
>

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