[PATCH] USB Storage: close a race condition in disconnect near queuecommand

This patch started life as as534, and has been re-diffed against the latest
tree.

usb-storage has a small loophole, a window between the time queuecommand
accepts a new command and the time the control thread starts to execute
it.  If disconnect is called during that window, the driver won't cancel
the pending command -- we've been relying on the SCSI core to cancel it
for us during host removal.  But it's better for usb-storage to cancel
it;  this avoids races and reduces reliance on the SCSI core.
Fortunately cancelling these commands is easy to do; the key is to do it
_before_ calling scsi_remove_host.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index 255771151399ada252af1d787a5b2121bbb6d8f0..97b9ebb8a0822aec492d9a53bce9e6ae666932b2 100644 (file)
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -833,6 +833,19 @@ static void quiesce_and_remove_host(struct us_data *us)
        /* Wait for the current command to finish, then remove the host */
        down(&us->dev_semaphore);
        up(&us->dev_semaphore);
+
+       /* queuecommand won't accept any new commands and the control
+        * thread won't execute a previously-queued command.  If there
+        * is such a command pending, complete it with an error. */
+       if (us->srb) {
+               us->srb->result = DID_NO_CONNECT << 16;
+               scsi_lock(us_to_host(us));
+               us->srb->scsi_done(us->srb);
+               us->srb = NULL;
+               scsi_unlock(us_to_host(us));
+       }
+
+       /* Now we own no commands so it's safe to remove the SCSI host */
        scsi_remove_host(us_to_host(us));
 }