[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 2/2] nbd/server: send more than one extent of base:allocation context
Date: Fri, 20 Jul 2018 15:42:05 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]