When SCSI was written, all commands coming from the filesystem
(REQ_TYPE_FS commands) had data. This meant that our signal for
needing to complete the command was the number of bytes completed being
equal to the number of bytes in the request. Unfortunately, with the
advent of flush barriers, we can now get zero length REQ_TYPE_FS
commands, which confuse this logic because they satisfy the condition
every time. This means they never get retried even for retryable
conditions, like UNIT ATTENTION because we complete them early assuming
they're done. Fix this by special casing the early completion
condition to recognise zero length commands with errors and let them
drop through to the retry code.
Reported-by: Sebastian Parschauer <s.parscha...@gmx.de>
Signed-off-by: James E.J. Bottomley <j...@linux.vnet.ibm.com>
---
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 8106515..f704d02 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -911,9 +911,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned
int good_bytes)
}
/*
- * If we finished all bytes in the request we are done now.
+ * special case: failed zero length commands always need to
+ * drop down into the retry code. Otherwise, if we finished
+ * all bytes in the request we are done now.
*/
- if (!scsi_end_request(req, error, good_bytes, 0))
+ if (!(blk_rq_bytes(req) == 0 && error) &&
+ !scsi_end_request(req, error, good_bytes, 0))
return;
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
