Re: [Qemu-devel] [PATCH 2/2] nbd/server: send more than one extent of base:allocation context

[Eric Blake <eblake@redhat.com>]

On 07/10/2018 09:33 AM, Vladimir Sementsov-Ogievskiy wrote:
> 04.07.2018 14:23, Vladimir Sementsov-Ogievskiy wrote:
>> This is necessary for efficient block-status export, for clients which
>> support it.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---

>> +static int blockstatus_to_extents(BlockDriverState *bs, uint64_t offset,
>> +                                  uint64_t *bytes, NBDExtent *extents,
>> +                                  unsigned int *nb_extents)
>>   {
>> -    uint64_t remaining_bytes = bytes;
>> +    uint64_t remaining_bytes = *bytes;
>> +    NBDExtent *extent = extents, *extents_end = extents + *nb_extents;
>> +    bool first_extent = true;
>> +    assert(*nb_extents);
>>       while (remaining_bytes) {
>>           uint32_t flags;
>>           int64_t num;
>> @@ -1860,21 +1871,40 @@ static int 
>> blockstatus_to_extent_be(BlockDriverState *bs, uint64_t offset,
> 
> after bdrv_block_status_above, is there a guarantee that num > 0? Should 
> we add an assertion?

bdrv_block_status_above() asserts that drivers set *pnum to non-zero on 
success (that is, a driver's .bdrv_co_block_status must make progress or 
fail); however, a caller can still get *pnum == 0 on the corner case of 
requesting status at or beyond the end-of-file boundary (where 
bdrv_block_status_above() does not call into a driver's 
.bdrv_co_block_status callback).  Since the NBD code already validated 
that the client's code does not exceed EOF, and the block layer 
guaranteed that an in-range request made progress on success, you should 
be fine with an assertion that num > 0.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org