Re: [Qemu-devel] [PATCH v2 14/17] block: Switch transfer length bounds to byte-based
On 06/21/2016 07:50 AM, Kevin Wolf wrote:
> Am 14.06.2016 um 23:30 hat Eric Blake geschrieben:
>> Sector-based limits are awkward to think about; in our on-going
>> quest to move to byte-based interfaces, convert max_transfer_length
>> and opt_transfer_length. Rename them (dropping the _length suffix)
>> so that the compiler will help us catch the change in semantics
>> across any rebased code, and improve the documentation. Use unsigned
>> values, so that we don't have to worry about negative values and
>> so that bit-twiddling is easier; however, we are still constrained
>> by 2^31 of signed int in most APIs.
>>
>> Signed-off-by: Eric Blake
>
>> @@ -1738,8 +1742,8 @@ static void iscsi_refresh_limits(BlockDriverState *bs,
>> Error **errp)
>> } else {
>> bs->bl.pwrite_zeroes_alignment = iscsilun->block_size;
>> }
>> -bs->bl.opt_transfer_length =
>> -sector_limits_lun2qemu(iscsilun->bl.opt_xfer_len, iscsilun);
>> +assert(iscsilun->bl.opt_xfer_len < INT_MAX / iscsilun->block_size);
>> +bs->bl.opt_transfer = iscsilun->bl.opt_xfer_len * iscsilun->block_size;
>> }
>
> iscsilun->bl.opt_xfer_len comes directly from libiscsi, and presumably
> from the iscsi server, without being checked or sanitised. I don't think
> we can assert a specific range of values for it but must assume that it
> can be any uint32_t.
>
> We can return an error for a device with a value that we don't like
> (even though using the maximum might be just fine), but crashing qemu is
> not an option.
I guess there's two possible problems: if the value is not a power of 2,
it affects how we want to use it (we probably ought to raise an error
there); and if it is oversized, we can just silently ignore the limit
(since we can't hit it). I'll see what I can come up with for v3.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 14/17] block: Switch transfer length bounds to byte-based
Am 14.06.2016 um 23:30 hat Eric Blake geschrieben:
> Sector-based limits are awkward to think about; in our on-going
> quest to move to byte-based interfaces, convert max_transfer_length
> and opt_transfer_length. Rename them (dropping the _length suffix)
> so that the compiler will help us catch the change in semantics
> across any rebased code, and improve the documentation. Use unsigned
> values, so that we don't have to worry about negative values and
> so that bit-twiddling is easier; however, we are still constrained
> by 2^31 of signed int in most APIs.
>
> Signed-off-by: Eric Blake
> @@ -1738,8 +1742,8 @@ static void iscsi_refresh_limits(BlockDriverState *bs,
> Error **errp)
> } else {
> bs->bl.pwrite_zeroes_alignment = iscsilun->block_size;
> }
> -bs->bl.opt_transfer_length =
> -sector_limits_lun2qemu(iscsilun->bl.opt_xfer_len, iscsilun);
> +assert(iscsilun->bl.opt_xfer_len < INT_MAX / iscsilun->block_size);
> +bs->bl.opt_transfer = iscsilun->bl.opt_xfer_len * iscsilun->block_size;
> }
iscsilun->bl.opt_xfer_len comes directly from libiscsi, and presumably
from the iscsi server, without being checked or sanitised. I don't think
we can assert a specific range of values for it but must assume that it
can be any uint32_t.
We can return an error for a device with a value that we don't like
(even though using the maximum might be just fine), but crashing qemu is
not an option.
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index aacf132..f2bea85 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -752,7 +752,8 @@ static void raw_refresh_limits(BlockDriverState *bs,
> Error **errp)
> if (S_ISBLK(st.st_mode)) {
> int ret = hdev_get_max_transfer_length(s->fd);
> if (ret >= 0) {
> -bs->bl.max_transfer_length = ret;
> +assert(ret <= BDRV_REQUEST_MAX_SECTORS);
> +bs->bl.max_transfer = ret << BDRV_SECTOR_BITS;
> }
> }
> }
Same thing here.
Kevin
Re: [Qemu-devel] [PATCH v2 14/17] block: Switch transfer length bounds to byte-based
On Tue, 06/14 15:30, Eric Blake wrote: > Sector-based limits are awkward to think about; in our on-going > quest to move to byte-based interfaces, convert max_transfer_length > and opt_transfer_length. Rename them (dropping the _length suffix) > so that the compiler will help us catch the change in semantics > across any rebased code, and improve the documentation. Use unsigned > values, so that we don't have to worry about negative values and > so that bit-twiddling is easier; however, we are still constrained > by 2^31 of signed int in most APIs. > > Signed-off-by: Eric Blake Looks good apart from the scsi-generic blocksize calculation, which is not an issue of this patch. Reviewed-by: Fam Zheng
