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

[Eric Blake]

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 <address@hidden>
> > ---

> > +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