On Fri, May 13, 2016 at 9:04 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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.parschauer@xxxxxx> > Signed-off-by: James E.J. Bottomley <jejb@xxxxxxxxxxxxxxxxxx> > > --- > > 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; > > /* Hi James, Thanks for your new patch. I tested on my environment, works fine. You can add: Tested-by: Jack Wang <jinpu.wang@xxxxxxxxxxxxxxxx> -- Mit freundlichen Grüßen, Best Regards, Jack Wang Linux Kernel Developer Storage ProfitBricks GmbH The IaaS-Company. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
