NAK: [Utopic][PATCH] UBUNTU: SAUCE: Revert "sd: don't use scsi_setup_blk_pc_cmnd for flush requests"

Chris J Arges chris.j.arges at canonical.com
Tue Sep 30 18:55:30 UTC 2014


My revert changes a potential fix:

rq->timeout = rq->q->rq_timeout * SD_FLUSH_TIMEOUT_MULTIPLIER;

Will post a v2 shortly.
--chris


On 09/30/2014 01:50 PM, Chris J Arges wrote:
> BugLink: http://bugs.launchpad.net/bugs/1375452
> 
> This reverts commit 32f7682bb0f71eaf88388e05af00cbc14edc9bd7.
> 
> Signed-off-by: Chris J Arges <chris.j.arges at canonical.com>
> 
> Conflicts:
> 	drivers/scsi/sd.c
> ---
>  drivers/scsi/sd.c | 20 +++++++-------------
>  1 file changed, 7 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index bb77c0e..ed2e99e 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -830,20 +830,14 @@ static int sd_setup_write_same_cmnd(struct scsi_device *sdp, struct request *rq)
>  	return ret;
>  }
>  
> -static int sd_setup_flush_cmnd(struct scsi_cmnd *cmd)
> +static int scsi_setup_flush_cmnd(struct scsi_device *sdp, struct request *rq)
>  {
> -	struct request *rq = cmd->request;
> +	rq->timeout *= SD_FLUSH_TIMEOUT_MULTIPLIER;
> +	rq->retries = SD_MAX_RETRIES;
> +	rq->cmd[0] = SYNCHRONIZE_CACHE;
> +	rq->cmd_len = 10;
>  
> -	/* flush requests don't perform I/O, zero the S/G table */
> -	memset(&cmd->sdb, 0, sizeof(cmd->sdb));
> -
> -	cmd->cmnd[0] = SYNCHRONIZE_CACHE;
> -	cmd->cmd_len = 10;
> -	cmd->transfersize = 0;
> -	cmd->allowed = SD_MAX_RETRIES;
> -
> -	rq->timeout = rq->q->rq_timeout * SD_FLUSH_TIMEOUT_MULTIPLIER;
> -	return BLKPREP_OK;
> +	return scsi_setup_blk_pc_cmnd(sdp, rq);
>  }
>  
>  static void sd_uninit_command(struct scsi_cmnd *SCpnt)
> @@ -883,7 +877,7 @@ static int sd_init_command(struct scsi_cmnd *SCpnt)
>  		ret = sd_setup_write_same_cmnd(sdp, rq);
>  		goto out;
>  	} else if (rq->cmd_flags & REQ_FLUSH) {
> -		ret = sd_setup_flush_cmnd(SCpnt);
> +		ret = scsi_setup_flush_cmnd(sdp, rq);
>  		goto out;
>  	}
>  	ret = scsi_setup_fs_cmnd(sdp, rq);
> 




More information about the kernel-team mailing list