[PATCH 4/4] sd: remove __data_len hack for WRITE SAME

Hannes Reinecke hare at suse.de
Fri Jan 13 03:44:16 PST 2017


On 01/13/2017 12:29 PM, Christoph Hellwig wrote:
> Now that we have the blk_rq_payload_bytes helper available to determine
> the actual I/O size we don't need to mess around with __data_len for
> WRITE SAME.
> 
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> ---
>  drivers/scsi/sd.c | 17 +----------------
>  1 file changed, 1 insertion(+), 16 deletions(-)
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index b193304..1fbb1ec 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -836,7 +836,6 @@ static int sd_setup_write_same_cmnd(struct scsi_cmnd *cmd)
>  	struct bio *bio = rq->bio;
>  	sector_t sector = blk_rq_pos(rq);
>  	unsigned int nr_sectors = blk_rq_sectors(rq);
> -	unsigned int nr_bytes = blk_rq_bytes(rq);
>  	int ret;
>  
>  	if (sdkp->device->no_write_same)
> @@ -869,21 +868,7 @@ static int sd_setup_write_same_cmnd(struct scsi_cmnd *cmd)
>  
>  	cmd->transfersize = sdp->sector_size;
>  	cmd->allowed = SD_MAX_RETRIES;
> -
> -	/*
> -	 * For WRITE_SAME the data transferred in the DATA IN buffer is
> -	 * different from the amount of data actually written to the target.
> -	 *
> -	 * We set up __data_len to the amount of data transferred from the
> -	 * DATA IN buffer so that blk_rq_map_sg set up the proper S/G list
> -	 * to transfer a single sector of data first, but then reset it to
> -	 * the amount of data to be written right after so that the I/O path
> -	 * knows how much to actually write.
> -	 */
> -	rq->__data_len = sdp->sector_size;
> -	ret = scsi_init_io(cmd);
> -	rq->__data_len = nr_bytes;
> -	return ret;
> +	return scsi_init_io(cmd);
>  }
>  
>  static int sd_setup_flush_cmnd(struct scsi_cmnd *cmd)
> 
Reviewed-by: Hannes Reinecke <hare at suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare at suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)



More information about the Linux-nvme mailing list