Re: Reproducible deadlock when usb-storage scsi command timeouts twice

[Oliver Neukum <oneukum@suse.com>]

On 03.05.23 14:51, Benjamin Block wrote:

>> usb-storage can do a reset only on the USB device level,
>> which translates to a bus reset on the SCSI level.
>>
>> And we are supposed to cancel any communication with the device
>> before that.
> 
> Is that a limitation of the devices or drivers? Because then you don't
> match SCSI semantics for LU reset - which aborts all running commands

We do not support a LUN reset. That's a limitation of the protocol.
If something goes wrong you need to reset the whole USB device, which
corresponds to a host adaptor on the SCSI level.

> on that scope among things. Which might explain the reason/choice behind
> this unexpected behavior for you.

For the device a reset presumably does wipe out the command currently
under execution. The problem is within the driver. It thinks that
a command is still active. And we are limited to one command at a time
(on the whole bus - again protocol limitation)

> On random thought I had: in theory you could implement your own EH
> strategy handler if the default one doesn't work for you. ATA and SAS do so.
> [drivers/scsi/scsi_error.c:2285 `shost->transportt->eh_strategy_handler()`]
> This can re-use parts/all of the existing escalation sequence in
> `scsi_eh_ready_devs()`.
> 
> But that's no short-term fix.

That looks like using a sledge hammer.

	Regards
		Oliver