From: Matthew Dharm Date: Thu, 28 Jul 2005 21:45:50 +0000 (-0700) Subject: [PATCH] USB Storage: close a race condition in disconnect near queuecommand X-Git-Tag: v2.6.14-rc1~492^2~18^2~32 X-Git-Url: https://err.no/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=26186ba77b493204ae0fadc3c88a67b14f22168f;p=linux-2.6 [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 Signed-off-by: Matthew Dharm Signed-off-by: Greg Kroah-Hartman --- diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c index 2557711513..97b9ebb8a0 100644 --- 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)); }