Hello,

Boaz Harrosh wrote:
quoted text
> I did not go to the bottom of this but how does that do not change
> user-space API. It would now fail in code that would work before.
> 
> What if I want to try variable size commands, where I try the
> shorter first, then a longer one (or vis versa). I would setup
> memory mapping to the biggest command but issue a length that
> correspond to the encoded command inside the CDB.
> 
> The bi->bi_size is not only mapping size it is also the command size
> I want to actually read/write.
> 
> But I might read this wrong though

Please see below.

quoted text
>> diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
>> index 73cfd91..fd538f8 100644
>> --- a/block/scsi_ioctl.c
>> +++ b/block/scsi_ioctl.c
>> @@ -288,7 +288,6 @@ static int sg_io(struct request_queue *q, struct gendisk *bd_disk,
>>  
>>  	if (hdr->iovec_count) {
>>  		const int size = sizeof(struct sg_iovec) * hdr->iovec_count;
>> -		size_t iov_data_len;
>>  		struct iovec *iov;
>>  
>>  		iov = kmalloc(size, GFP_KERNEL);
>> @@ -304,15 +303,11 @@ static int sg_io(struct request_queue *q, struct gendisk *bd_disk,
>>  		}
>>  
>>  		/* SG_IO howto says that the shorter of the two wins */
>> -		iov_data_len = iov_length(iov, hdr->iovec_count);
>> -		if (hdr->dxfer_len < iov_data_len) {
>> -			hdr->iovec_count = iov_shorten(iov, hdr->iovec_count,
>> -						       hdr->dxfer_len);
>> -			iov_data_len = hdr->dxfer_len;
>> -		}
>> +		hdr->iovec_count = iov_shorten(iov, hdr->iovec_count,
>> +					       hdr->dxfer_len);
>>  
>>  		ret = blk_rq_map_user_iov(q, rq, NULL, iov, hdr->iovec_count,
>> -					  iov_data_len, GFP_KERNEL);
>> +					  GFP_KERNEL);

blk_rq_map_user_iov() never had the shorter data len functionality.
It fails requests with -EINVAL if iov_length(iov) != dxfer_len, so a
patch in the previous patchset adds the above iov_shorten() call to
trim iov if dxfer_len is shorter.  In this patch, it gets a bit
simpler as the length parameter isn't necessary.

Thanks.

-- 
tejun
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/