Re: [PATCH 3/5] scsi: No retries on abort success

Hannes Reinecke
2020-08-10T06:19:38Z

On 8/5/20 4:51 AM, Muneendra wrote:
> Made an additional check in scsi_noretry_cmd to verify whether user has
> decided not to do retries on abort(issued on scsi timeouts) success by
> checking the SCMD_NORETRIES_ABORT bit
>
> If SCMD_NORETRIES_ABORT bit is set we are making sure there won't be any
> retries done on the same path and also setting the host byte as
> DID_TRANSPORT_FAILFAST so that the error can be propogated as recoverable
> transport error to the blk layers.
>
> Signed-off-by: Muneendra <muneendra.kumar@broadcom.com>
> ---
> drivers/scsi/scsi_error.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 927b1e6..3222496 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -1749,6 +1749,16 @@ int scsi_noretry_cmd(struct scsi_cmnd *scmd)
>
> check_type:
> /*
> + * Check whether caller has decided not to do retries on
> + * abort success by setting the SCMD_NORETRIES_ABORT bit
> + */
> + if ((test_bit(SCMD_NORETRIES_ABORT, &scmd->state)) &&
> + (scmd->request->cmd_flags & REQ_FAILFAST_TRANSPORT)) {
> + set_host_byte(scmd, DID_TRANSPORT_FAILFAST);
> + return 1;
> + }
> +
> + /*
> * assume caller has checked sense and determined
> * the check condition was retryable.
> */
>
_Actually_ DID_TRANSPORT_FAILFAST is just for transport aborted
commands, so maybe we should use a different error code (or add a new one).
But other than that:

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer