On 4/26/23 12:20, Alan Stern wrote:
This patch fixes the issue, not sure if it's correct:
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -455,6 +455,9 @@ static int device_reset(struct scsi_cmnd *srb)
usb_stor_dbg(us, "%s called\n", __func__);
+ if (us->srb == srb)
+ command_abort(srb);
+
/* lock the device pointers and do the reset */
mutex_lock(&(us->dev_mutex));
result = us->transport_reset(us);
Maybe... But it would be better to check first whether the SCSI core is
supposed to be reusing an active srb in this way.
Martin, can tell us what is supposed to happen here? Is the
eh_device_reset_handler routine supposed to be called with a scsi_cmnd
for a currently active command?
Hi Alan,
I'm not aware of any other .eh_device_reset_handler implementation that
aborts the command that is passed to this callback before it aborts
other SCSI commands. However, I'm not aware of an equivalent of
us_data.dev_mutex in other SCSI LLDs either. Maybe this deadlock is
specific to the USB storage handler?
Martin, feel free to correct me if I got anything wrong.
Bart.
