]> git.karo-electronics.de Git - karo-tx-linux.git/commit
[SCSI] Fix USB deadlock caused by SCSI error handling
authorHannes Reinecke <hare@suse.de>
Mon, 31 Mar 2014 14:37:34 +0000 (16:37 +0200)
committerJames Bottomley <JBottomley@Parallels.com>
Mon, 21 Apr 2014 17:58:15 +0000 (10:58 -0700)
commit12023e77f4986026928f157df5c0d6bded4d632f
tree7624f3183962f55d01112f09eff32b3c5d975833
parent1a868fe865204652dd0f477b24dbfc46e282427f
[SCSI] Fix USB deadlock caused by SCSI error handling

USB requires that every command be aborted first before we escalate to reset.
In particular, USB will deadlock if we try to reset first before aborting the
command.

Unfortunately, the flag we use to tell if a command has already been aborted:
SCSI_EH_ABORT_SCHEDULED is not cleared properly leading to cases where we can
requeue a command with the flag set and proceed immediately to reset if it
fails (thus causing USB to deadlock).

Fix by clearing the SCSI_EH_ABORT_SCHEDULED flag if it has been set.  Which
means this will be the second time scsi_abort_command() has been called for
the same command.  IE the first abort went out, did its thing, but now the
same command has timed out again.

So this flag gets cleared, and scsi_abort_command() returns FAILED, and _no_
asynchronous abort is being scheduled.  scsi_times_out() will then proceed to
call scsi_eh_scmd_add().  But as we've cleared the SCSI_EH_ABORT_SCHEDULED
flag the SCSI_EH_CANCEL_CMD flag will continue to be set, and the command will
be aborted with the main SCSI EH routine.

Reported-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
drivers/scsi/scsi_error.c