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 <vsement...@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
