Re: [PATCH v2] usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer

[Owen Gu]

On Mon, Oct 27, 2025 at 02:35:37PM +0100, Oliver Neukum wrote:
> Hi,
> 
> I think I was unclear the first time.
> Sorry for that.
> 
> On 27.10.25 07:05, Owen Gu wrote:
> > Hi Oliver,
> > 
> 
> > > This patch modifies the error condition check in the uas_submit_urbs()
> > > function. When a UAS device is removed but one or more URBs have already
> > > been successfully submitted to USB, it avoids immediately invoking
> > > scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully
> > > submitted URBs is completed before devinfo->resetting being set, then
> > > the scsi_done() function will be called within uas_try_complete() after
> 
> This requires that uas_try_complete() is called.
> 
> And I am afraid uas_stat_cmplt() cannot guarantee that in the error case.
> I think the following sequence of events is possible:
> 
> CPU A						CPU B
> 
> uas_queuecommand_lck() calls uas_submit_urbs()
> COMMAND_INFLIGHT is set and URB submitted
> 						URB gets an error
> 						status = -EBABBLE (just an example)
> 						uas_stat_cmplt is called
> 						resetting is not set
> 						if (status)
> 							goto out;
> 
> 						uas_try_complete _not_ called
> 
> The scsi command runs for indeterminate amount of time.
> It seems to me that if you want to use your approach you also
> need to change error handling in uas_stat_cmplt()
> 
> 	Regards
> 		Oliver
> 
>
Hi Oliver,
I think the error handling only takes effect when uas_queuecommand_lck() calls
uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is
disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is
invoked to call uas_try_complete().

Regards
Owen