Hi,
it seems to that there's a small window for the storage
driver to reject a command (and log an error) at the completion
of a command. Something like this patch should fix it.
What do you think?
Regards
Oliver
>From 67a8e1de3279a2f86dda4c9b424d41ca85aaa735 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@xxxxxxx>
Date: Wed, 1 Oct 2014 13:23:35 +0200
Subject: [PATCH] usb-storage: fix race between done and queuecommand
queuecommand_lck() enforces the one command at a time rule
by recording the currently active command in us->srb and returning
SCSI_MLQUEUE_HOST_BUSY if it is called while a command is still
active. This opens a window when the upper layers already have
been informed about the current commands completion by a call
to scsi_done() but the driver is not ready to accept the next command.
To fix this the current command must be set to NULL before scsi_done()
is called.
Signed-off-by: Oliver Neukum <oneukum@xxxxxxx>
---
drivers/usb/storage/usb.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index ef90581..def24e6 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -304,6 +304,7 @@ static int usb_stor_control_thread(void * __us)
{
struct us_data *us = (struct us_data *)__us;
struct Scsi_Host *host = us_to_host(us);
+ struct scsi_cmnd *temp;
for (;;) {
usb_stor_dbg(us, "*** thread sleeping\n");
@@ -387,9 +388,12 @@ static int usb_stor_control_thread(void * __us)
if (us->srb->result != DID_ABORT << 16) {
usb_stor_dbg(us, "scsi cmd done, result=0x%x\n",
us->srb->result);
- us->srb->scsi_done(us->srb);
+ temp = us->srb;
+ us->srb = NULL;
+ us->srb->scsi_done(temp);
} else {
SkipForAbort:
+ us->srb = NULL;
usb_stor_dbg(us, "scsi command aborted\n");
}
@@ -407,7 +411,6 @@ SkipForAbort:
}
/* finished working on this command */
- us->srb = NULL;
scsi_unlock(host);
/* unlock the device pointers */
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
