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 <ebl...@redhat.com> > >> @@ -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