On Fri, May 13, 2016 at 9:04 PM, James Bottomley
<[email protected]> 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 <[email protected]>
> Signed-off-by: James E.J. Bottomley <[email protected]>
>
> ---
>
> 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 <[email protected]>
-- 
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to