[PATCH v5 0/5] fix & merge block_status_above and is_allocated_above

[PATCH v5 0/5] fix & merge block_status_above and is_allocated_above

[Vladimir Sementsov-Ogievskiy]

v5: rebase on coroutine-wrappers series, 02 changed correspondingly

Based on series "[PATCH v7 0/7] coroutines: generate wrapper code", or
in other words:
Based-on: <20200610100336.23451-1-vsementsov@virtuozzo.com>

Hi all!

These series are here to address the following problem:
block-status-above functions may consider space after EOF of
intermediate backing files as unallocated, which is wrong, as these
backing files are the reason of producing zeroes, we never go further by
backing chain after a short backing file. So, if such short-backing file
is _inside_ requested sub-chain of the backing chain, we should never
report space after its EOF as unallocated.

See patches 01,04,05 for details.

Note, that this series leaves for another day the general problem
around block-status: misuse of BDRV_BLOCK_ALLOCATED as is-fs-allocated
vs go-to-backing.
Audit for this problem is done here:
"backing chain & block status & filters"
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg04706.html
And I'm going to prepare series to address this problem.

Also, get_block_status func have same disease, but remains unfixed here:
I want to make separate series for it, as it need some more refactoring,
which should be based on series
"[PATCH v5 0/7] coroutines: generate wrapper code"

Vladimir Sementsov-Ogievskiy (5):
  block/io: fix bdrv_co_block_status_above
  block/io: bdrv_common_block_status_above: support include_base
  block/io: bdrv_common_block_status_above: support bs == base
  block/io: fix bdrv_is_allocated_above
  iotests: add commit top->base cases to 274

 block/coroutines.h         |   2 +
 block/io.c                 | 100 ++++++++++++++++++-------------------
 block/qcow2.c              |  16 +++++-
 tests/qemu-iotests/274     |  20 ++++++++
 tests/qemu-iotests/274.out |  65 ++++++++++++++++++++++++
 5 files changed, 150 insertions(+), 53 deletions(-)

-- 
2.21.0

[PATCH v5 1/5] block/io: fix bdrv_co_block_status_above

[Vladimir Sementsov-Ogievskiy]

bdrv_co_block_status_above has several design problems with handling
short backing files:

1. With want_zeros=true, it may return ret with BDRV_BLOCK_ZERO but
without BDRV_BLOCK_ALLOCATED flag, when actually short backing file
which produces these after-EOF zeros is inside requested backing
sequence.

2. With want_zero=false, it may return pnum=0 prior to actual EOF,
because of EOF of short backing file.

Fix these things, making logic about short backing files clearer.

With fixed bdrv_block_status_above we also have to improve is_zero in
qcow2 code, otherwise iotest 154 will fail, because with this patch we
stop to merge zeros of different types (produced by fully unallocated
in the whole backing chain regions vs produced by short backing files).

Note also, that this patch leaves for another day the general problem
around block-status: misuse of BDRV_BLOCK_ALLOCATED as is-fs-allocated
vs go-to-backing.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
 block/io.c    | 39 ++++++++++++++++++++++++++++++---------
 block/qcow2.c | 16 ++++++++++++++--
 2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/block/io.c b/block/io.c
index 83ffc7d390..f2a89d9417 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2373,25 +2373,46 @@ bdrv_co_common_block_status_above(BlockDriverState *bs,
         ret = bdrv_co_block_status(p, want_zero, offset, bytes, pnum, map,
                                    file);
         if (ret < 0) {
-            break;
+            return ret;
         }
-        if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
+        if (*pnum == 0) {
+            if (first) {
+                return ret;
+            }
+
             /*
-             * Reading beyond the end of the file continues to read
-             * zeroes, but we can only widen the result to the
-             * unallocated length we learned from an earlier
-             * iteration.
+             * The top layer deferred to this layer, and because this layer is
+             * short, any zeroes that we synthesize beyond EOF behave as if they
+             * were allocated at this layer
              */
+            assert(ret & BDRV_BLOCK_EOF);
             *pnum = bytes;
+            if (file) {
+                *file = p;
+            }
+            return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;
         }
-        if (ret & (BDRV_BLOCK_ZERO | BDRV_BLOCK_DATA)) {
-            break;
+        if (ret & BDRV_BLOCK_ALLOCATED) {
+            /* We've found the node and the status, we must return. */
+
+            if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
+                /*
+                 * This level is also responsible for reads after EOF inside
+                 * the unallocated region in the previous level.
+                 */
+                *pnum = bytes;
+            }
+
+            return ret;
         }
+
         /* [offset, pnum] unallocated on this layer, which could be only
          * the first part of [offset, bytes].  */
-        bytes = MIN(bytes, *pnum);
+        assert(*pnum <= bytes);
+        bytes = *pnum;
         first = false;
     }
+
     return ret;
 }
 
diff --git a/block/qcow2.c b/block/qcow2.c
index 0cd2e6757e..ce4cf00770 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -3827,8 +3827,20 @@ static bool is_zero(BlockDriverState *bs, int64_t offset, int64_t bytes)
     if (!bytes) {
         return true;
     }
-    res = bdrv_block_status_above(bs, NULL, offset, bytes, &nr, NULL, NULL);
-    return res >= 0 && (res & BDRV_BLOCK_ZERO) && nr == bytes;
+
+    /*
+     * bdrv_block_status_above doesn't merge different types of zeros, for
+     * example, zeros which come from the region which is unallocated in
+     * the whole backing chain, and zeros which comes because of a short
+     * backing file. So, we need a loop.
+     */
+    do {
+        res = bdrv_block_status_above(bs, NULL, offset, bytes, &nr, NULL, NULL);
+        offset += nr;
+        bytes -= nr;
+    } while (res >= 0 && (res & BDRV_BLOCK_ZERO) && nr && bytes);
+
+    return res >= 0 && (res & BDRV_BLOCK_ZERO) && bytes == 0;
 }
 
 static coroutine_fn int qcow2_co_pwrite_zeroes(BlockDriverState *bs,
-- 
2.21.0

[PATCH v5 2/5] block/io: bdrv_common_block_status_above: support include_base

[Vladimir Sementsov-Ogievskiy]

In order to reuse bdrv_common_block_status_above in
bdrv_is_allocated_above, let's support include_base parameter.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 block/coroutines.h |  2 ++
 block/io.c         | 14 ++++++++++----
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/block/coroutines.h b/block/coroutines.h
index f69179f5ef..1cb3128b94 100644
--- a/block/coroutines.h
+++ b/block/coroutines.h
@@ -41,6 +41,7 @@ bdrv_pwritev(BdrvChild *child, int64_t offset, unsigned int bytes,
 int coroutine_fn
 bdrv_co_common_block_status_above(BlockDriverState *bs,
                                   BlockDriverState *base,
+                                  bool include_base,
                                   bool want_zero,
                                   int64_t offset,
                                   int64_t bytes,
@@ -50,6 +51,7 @@ bdrv_co_common_block_status_above(BlockDriverState *bs,
 int generated_co_wrapper
 bdrv_common_block_status_above(BlockDriverState *bs,
                                BlockDriverState *base,
+                               bool include_base,
                                bool want_zero,
                                int64_t offset,
                                int64_t bytes,
diff --git a/block/io.c b/block/io.c
index f2a89d9417..c3ef387f7e 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2357,6 +2357,7 @@ early_out:
 int coroutine_fn
 bdrv_co_common_block_status_above(BlockDriverState *bs,
                                   BlockDriverState *base,
+                                  bool include_base,
                                   bool want_zero,
                                   int64_t offset,
                                   int64_t bytes,
@@ -2368,8 +2369,8 @@ bdrv_co_common_block_status_above(BlockDriverState *bs,
     int ret = 0;
     bool first = true;
 
-    assert(bs != base);
-    for (p = bs; p != base; p = backing_bs(p)) {
+    assert(include_base || bs != base);
+    for (p = bs; include_base || p != base; p = backing_bs(p)) {
         ret = bdrv_co_block_status(p, want_zero, offset, bytes, pnum, map,
                                    file);
         if (ret < 0) {
@@ -2408,6 +2409,11 @@ bdrv_co_common_block_status_above(BlockDriverState *bs,
 
         /* [offset, pnum] unallocated on this layer, which could be only
          * the first part of [offset, bytes].  */
+
+        if (p == base) {
+            break;
+        }
+
         assert(*pnum <= bytes);
         bytes = *pnum;
         first = false;
@@ -2420,7 +2426,7 @@ int bdrv_block_status_above(BlockDriverState *bs, BlockDriverState *base,
                             int64_t offset, int64_t bytes, int64_t *pnum,
                             int64_t *map, BlockDriverState **file)
 {
-    return bdrv_common_block_status_above(bs, base, true, offset, bytes,
+    return bdrv_common_block_status_above(bs, base, false, true, offset, bytes,
                                           pnum, map, file);
 }
 
@@ -2437,7 +2443,7 @@ int coroutine_fn bdrv_is_allocated(BlockDriverState *bs, int64_t offset,
     int ret;
     int64_t dummy;
 
-    ret = bdrv_common_block_status_above(bs, backing_bs(bs), false, offset,
+    ret = bdrv_common_block_status_above(bs, bs, true, false, offset,
                                          bytes, pnum ? pnum : &dummy, NULL,
                                          NULL);
     if (ret < 0) {
-- 
2.21.0

[PATCH v5 3/5] block/io: bdrv_common_block_status_above: support bs == base

[Vladimir Sementsov-Ogievskiy]

We are going to reuse bdrv_common_block_status_above in
bdrv_is_allocated_above. bdrv_is_allocated_above may be called with
include_base == false and still bs == base (for ex. from img_rebase()).

So, support this corner case.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
 block/io.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/block/io.c b/block/io.c
index c3ef387f7e..3df3a5b8ee 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2369,7 +2369,11 @@ bdrv_co_common_block_status_above(BlockDriverState *bs,
     int ret = 0;
     bool first = true;
 
-    assert(include_base || bs != base);
+    if (!include_base && bs == base) {
+        *pnum = bytes;
+        return 0;
+    }
+
     for (p = bs; include_base || p != base; p = backing_bs(p)) {
         ret = bdrv_co_block_status(p, want_zero, offset, bytes, pnum, map,
                                    file);
-- 
2.21.0

[PATCH v5 4/5] block/io: fix bdrv_is_allocated_above

[Vladimir Sementsov-Ogievskiy]

bdrv_is_allocated_above wrongly handles short backing files: it reports
after-EOF space as UNALLOCATED which is wrong, as on read the data is
generated on the level of short backing file (if all overlays has
unallocated area at that place).

Reusing bdrv_common_block_status_above fixes the issue and unifies code
path.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
 block/io.c | 43 +++++--------------------------------------
 1 file changed, 5 insertions(+), 38 deletions(-)

diff --git a/block/io.c b/block/io.c
index 3df3a5b8ee..e80f7ad527 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2471,52 +2471,19 @@ int coroutine_fn bdrv_is_allocated(BlockDriverState *bs, int64_t offset,
  * at 'offset + *pnum' may return the same allocation status (in other
  * words, the result is not necessarily the maximum possible range);
  * but 'pnum' will only be 0 when end of file is reached.
- *
  */
 int bdrv_is_allocated_above(BlockDriverState *top,
                             BlockDriverState *base,
                             bool include_base, int64_t offset,
                             int64_t bytes, int64_t *pnum)
 {
-    BlockDriverState *intermediate;
-    int ret;
-    int64_t n = bytes;
-
-    assert(base || !include_base);
-
-    intermediate = top;
-    while (include_base || intermediate != base) {
-        int64_t pnum_inter;
-        int64_t size_inter;
-
-        assert(intermediate);
-        ret = bdrv_is_allocated(intermediate, offset, bytes, &pnum_inter);
-        if (ret < 0) {
-            return ret;
-        }
-        if (ret) {
-            *pnum = pnum_inter;
-            return 1;
-        }
-
-        size_inter = bdrv_getlength(intermediate);
-        if (size_inter < 0) {
-            return size_inter;
-        }
-        if (n > pnum_inter &&
-            (intermediate == top || offset + pnum_inter < size_inter)) {
-            n = pnum_inter;
-        }
-
-        if (intermediate == base) {
-            break;
-        }
-
-        intermediate = backing_bs(intermediate);
+    int ret = bdrv_common_block_status_above(top, base, include_base, false,
+                                             offset, bytes, pnum, NULL, NULL);
+    if (ret < 0) {
+        return ret;
     }
 
-    *pnum = n;
-    return 0;
+    return !!(ret & BDRV_BLOCK_ALLOCATED);
 }
 
 int coroutine_fn
-- 
2.21.0

[PATCH v5 5/5] iotests: add commit top->base cases to 274

[Vladimir Sementsov-Ogievskiy]

These cases are fixed by previous patches around block_status and
is_allocated.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
 tests/qemu-iotests/274     | 20 ++++++++++++
 tests/qemu-iotests/274.out | 65 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+)

diff --git a/tests/qemu-iotests/274 b/tests/qemu-iotests/274
index 5d1bf34dff..e910455f13 100755
--- a/tests/qemu-iotests/274
+++ b/tests/qemu-iotests/274
@@ -115,6 +115,26 @@ with iotests.FilePath('base') as base, \
     iotests.qemu_io_log('-c', 'read -P 1 0 %d' % size_short, mid)
     iotests.qemu_io_log('-c', 'read -P 0 %d %d' % (size_short, size_diff), mid)
 
+    iotests.log('=== Testing qemu-img commit (top -> base) ===')
+
+    create_chain()
+    iotests.qemu_img_log('commit', '-b', base, top)
+    iotests.img_info_log(base)
+    iotests.qemu_io_log('-c', 'read -P 1 0 %d' % size_short, base)
+    iotests.qemu_io_log('-c', 'read -P 0 %d %d' % (size_short, size_diff), base)
+
+    iotests.log('=== Testing QMP active commit (top -> base) ===')
+
+    create_chain()
+    with create_vm() as vm:
+        vm.launch()
+        vm.qmp_log('block-commit', device='top', base_node='base',
+                   job_id='job0', auto_dismiss=False)
+        vm.run_job('job0', wait=5)
+
+    iotests.img_info_log(mid)
+    iotests.qemu_io_log('-c', 'read -P 1 0 %d' % size_short, base)
+    iotests.qemu_io_log('-c', 'read -P 0 %d %d' % (size_short, size_diff), base)
 
     iotests.log('== Resize tests ==')
 
diff --git a/tests/qemu-iotests/274.out b/tests/qemu-iotests/274.out
index d24ff681af..9806dea8b6 100644
--- a/tests/qemu-iotests/274.out
+++ b/tests/qemu-iotests/274.out
@@ -129,6 +129,71 @@ read 1048576/1048576 bytes at offset 0
 read 1048576/1048576 bytes at offset 1048576
 1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 
+=== Testing qemu-img commit (top -> base) ===
+Formatting 'TEST_DIR/PID-base', fmt=qcow2 size=2097152 cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
+
+Formatting 'TEST_DIR/PID-mid', fmt=qcow2 size=1048576 backing_file=TEST_DIR/PID-base cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
+
+Formatting 'TEST_DIR/PID-top', fmt=qcow2 size=2097152 backing_file=TEST_DIR/PID-mid cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
+
+wrote 2097152/2097152 bytes at offset 0
+2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+Image committed.
+
+image: TEST_IMG
+file format: IMGFMT
+virtual size: 2 MiB (2097152 bytes)
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+
+read 1048576/1048576 bytes at offset 0
+1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+read 1048576/1048576 bytes at offset 1048576
+1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+=== Testing QMP active commit (top -> base) ===
+Formatting 'TEST_DIR/PID-base', fmt=qcow2 size=2097152 cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
+
+Formatting 'TEST_DIR/PID-mid', fmt=qcow2 size=1048576 backing_file=TEST_DIR/PID-base cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
+
+Formatting 'TEST_DIR/PID-top', fmt=qcow2 size=2097152 backing_file=TEST_DIR/PID-mid cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
+
+wrote 2097152/2097152 bytes at offset 0
+2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+{"execute": "block-commit", "arguments": {"auto-dismiss": false, "base-node": "base", "device": "top", "job-id": "job0"}}
+{"return": {}}
+{"execute": "job-complete", "arguments": {"id": "job0"}}
+{"return": {}}
+{"data": {"device": "job0", "len": 1048576, "offset": 1048576, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_READY", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+{"data": {"device": "job0", "len": 1048576, "offset": 1048576, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+{"execute": "job-dismiss", "arguments": {"id": "job0"}}
+{"return": {}}
+image: TEST_IMG
+file format: IMGFMT
+virtual size: 1 MiB (1048576 bytes)
+cluster_size: 65536
+backing file: TEST_DIR/PID-base
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+
+read 1048576/1048576 bytes at offset 0
+1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+read 1048576/1048576 bytes at offset 1048576
+1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
 == Resize tests ==
 === preallocation=off ===
 Formatting 'TEST_DIR/PID-base', fmt=qcow2 size=6442450944 cluster_size=65536 lazy_refcounts=off refcount_bits=16 compression_type=zlib
-- 
2.21.0

Re: [PATCH v5 0/5] fix & merge block_status_above and is_allocated_above

[Vladimir Sementsov-Ogievskiy]

ping :)

10.06.2020 15:04, Vladimir Sementsov-Ogievskiy wrote:
> v5: rebase on coroutine-wrappers series, 02 changed correspondingly
> 
> Based on series "[PATCH v7 0/7] coroutines: generate wrapper code", or
> in other words:
> Based-on: <20200610100336.23451-1-vsementsov@virtuozzo.com>
> 
> Hi all!
> 
> These series are here to address the following problem:
> block-status-above functions may consider space after EOF of
> intermediate backing files as unallocated, which is wrong, as these
> backing files are the reason of producing zeroes, we never go further by
> backing chain after a short backing file. So, if such short-backing file
> is _inside_ requested sub-chain of the backing chain, we should never
> report space after its EOF as unallocated.
> 
> See patches 01,04,05 for details.
> 
> Note, that this series leaves for another day the general problem
> around block-status: misuse of BDRV_BLOCK_ALLOCATED as is-fs-allocated
> vs go-to-backing.
> Audit for this problem is done here:
> "backing chain & block status & filters"
> https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg04706.html
> And I'm going to prepare series to address this problem.
> 
> Also, get_block_status func have same disease, but remains unfixed here:
> I want to make separate series for it, as it need some more refactoring,
> which should be based on series
> "[PATCH v5 0/7] coroutines: generate wrapper code"
> 
> Vladimir Sementsov-Ogievskiy (5):
>    block/io: fix bdrv_co_block_status_above
>    block/io: bdrv_common_block_status_above: support include_base
>    block/io: bdrv_common_block_status_above: support bs == base
>    block/io: fix bdrv_is_allocated_above
>    iotests: add commit top->base cases to 274
> 
>   block/coroutines.h         |   2 +
>   block/io.c                 | 100 ++++++++++++++++++-------------------
>   block/qcow2.c              |  16 +++++-
>   tests/qemu-iotests/274     |  20 ++++++++
>   tests/qemu-iotests/274.out |  65 ++++++++++++++++++++++++
>   5 files changed, 150 insertions(+), 53 deletions(-)
> 


-- 
Best regards,
Vladimir

Re: [PATCH v5 1/5] block/io: fix bdrv_co_block_status_above

[Alberto Garcia]

On Wed 10 Jun 2020 02:04:22 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> +             * The top layer deferred to this layer, and because this layer is
> +             * short, any zeroes that we synthesize beyond EOF behave as if they
> +             * were allocated at this layer
>               */
> +            assert(ret & BDRV_BLOCK_EOF);
>              *pnum = bytes;
> +            if (file) {
> +                *file = p;
> +            }
> +            return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;

You don't add BDRV_BLOCK_EOF to the return code here ?

> +        res = bdrv_block_status_above(bs, NULL, offset, bytes, &nr, NULL, NULL);
> +        offset += nr;
> +        bytes -= nr;
> +    } while (res >= 0 && (res & BDRV_BLOCK_ZERO) && nr && bytes);

About this last "... && nr && bytes", I think 'nr' already implies
'bytes', maybe you want to use an assertion instead?

Berto

Re: [PATCH v5 2/5] block/io: bdrv_common_block_status_above: support include_base

[Alberto Garcia]

On Wed 10 Jun 2020 02:04:23 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> In order to reuse bdrv_common_block_status_above in
> bdrv_is_allocated_above, let's support include_base parameter.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

Reviewed-by: Alberto Garcia <berto@igalia.com>

Berto

Re: [PATCH v5 3/5] block/io: bdrv_common_block_status_above: support bs == base

[Alberto Garcia]

On Wed 10 Jun 2020 02:04:24 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> We are going to reuse bdrv_common_block_status_above in
> bdrv_is_allocated_above. bdrv_is_allocated_above may be called with
> include_base == false and still bs == base (for ex. from img_rebase()).
>
> So, support this corner case.

Reviewed-by: Alberto Garcia <berto@igalia.com>

Berto

Re: [PATCH v5 4/5] block/io: fix bdrv_is_allocated_above

[Alberto Garcia]

On Wed 10 Jun 2020 02:04:25 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> bdrv_is_allocated_above wrongly handles short backing files: it reports
> after-EOF space as UNALLOCATED which is wrong, as on read the data is
> generated on the level of short backing file (if all overlays has
> unallocated area at that place).
>
> Reusing bdrv_common_block_status_above fixes the issue and unifies code
> path.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>

Reviewed-by: Alberto Garcia <berto@igalia.com>

Berto

Re: [PATCH v5 5/5] iotests: add commit top->base cases to 274

[Alberto Garcia]

On Wed 10 Jun 2020 02:04:26 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> These cases are fixed by previous patches around block_status and
> is_allocated.

Reviewed-by: Alberto Garcia <berto@igalia.com>

Berto

Re: [PATCH v5 1/5] block/io: fix bdrv_co_block_status_above

[Vladimir Sementsov-Ogievskiy]

Thanks a lot for reviewing!

18.08.2020 17:15, Alberto Garcia wrote:
> On Wed 10 Jun 2020 02:04:22 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
>> +             * The top layer deferred to this layer, and because this layer is
>> +             * short, any zeroes that we synthesize beyond EOF behave as if they
>> +             * were allocated at this layer
>>                */
>> +            assert(ret & BDRV_BLOCK_EOF);
>>               *pnum = bytes;
>> +            if (file) {
>> +                *file = p;
>> +            }
>> +            return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;
> 
> You don't add BDRV_BLOCK_EOF to the return code here ?

No we shouldn't, as this is the end of backing file when the top layer is larger.

> 
>> +        res = bdrv_block_status_above(bs, NULL, offset, bytes, &nr, NULL, NULL);
>> +        offset += nr;
>> +        bytes -= nr;
>> +    } while (res >= 0 && (res & BDRV_BLOCK_ZERO) && nr && bytes);
> 
> About this last "... && nr && bytes", I think 'nr' already implies
> 'bytes', maybe you want to use an assertion instead?

No, on the last iteration, bytes would be 0 and nr is a last chunk. So, if we check
only nr, we'll do one extra call of bdrv_block_status_above with bytes=0, I don't
want do it.

> 
> Berto
> 


-- 
Best regards,
Vladimir

Re: [PATCH v5 1/5] block/io: fix bdrv_co_block_status_above

[Alberto Garcia]

On Wed 19 Aug 2020 11:48:25 AM CEST, Vladimir Sementsov-Ogievskiy wrote:
>>> +             * The top layer deferred to this layer, and because this layer is
>>> +             * short, any zeroes that we synthesize beyond EOF behave as if they
>>> +             * were allocated at this layer
>>>                */
>>> +            assert(ret & BDRV_BLOCK_EOF);
>>>               *pnum = bytes;
>>> +            if (file) {
>>> +                *file = p;
>>> +            }
>>> +            return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;
>> 
>> You don't add BDRV_BLOCK_EOF to the return code here ?
>
> No we shouldn't, as this is the end of backing file when the top layer
> is larger.

Ok, but maybe the original request also reaches EOF on the top layer.

An example that does not actually involve short backing files: let's say
that the size of the active image is 1MB and the backing file is 2MB.

We do 'write -z 960k 63k', that zeroes the last cluster minus a 1KB
tail, so qcow2_co_pwrite_zeroes() calls is_zero() to check if that last
1KB already contains zeroes.

bdrv_co_block_status_above() on the top layer returns BDRV_BLOCK_EOF: no
allocation, no zeros, we simply reached EOF. So we go to the backing
image to see what's there. This is also unallocated, there's no backing
file this time and want_zero is set, so this returns BDRV_BLOCK_ZERO.
However the backing file is longer so bdrv_co_block_status() does not
return BDRV_BLOCK_EOF this time.

If the backing file would have been the same size (1MB) we would have
BDRV_BLOCK_ZERO | BDRV_BLOCK_EOF, but if it's longer or (with your
patch) shorter then BDRV_BLOCK_EOF disappears.

Now, I don't see anyone else using BDRV_BLOCK_EOF for anything so this
does not have any practical effect at the moment, but is this worth
fixing?.

>>> +        res = bdrv_block_status_above(bs, NULL, offset, bytes, &nr, NULL, NULL);
>>> +        offset += nr;
>>> +        bytes -= nr;
>>> +    } while (res >= 0 && (res & BDRV_BLOCK_ZERO) && nr && bytes);
>> 
>> About this last "... && nr && bytes", I think 'nr' already implies
>> 'bytes', maybe you want to use an assertion instead?
>
> No, on the last iteration, bytes would be 0 and nr is a last
> chunk. So, if we check only nr, we'll do one extra call of
> bdrv_block_status_above with bytes=0, I don't want do it.

You're right !

Berto

Re: [PATCH v5 1/5] block/io: fix bdrv_co_block_status_above

[Vladimir Sementsov-Ogievskiy]

19.08.2020 14:34, Alberto Garcia wrote:
> On Wed 19 Aug 2020 11:48:25 AM CEST, Vladimir Sementsov-Ogievskiy wrote:
>>>> +             * The top layer deferred to this layer, and because this layer is
>>>> +             * short, any zeroes that we synthesize beyond EOF behave as if they
>>>> +             * were allocated at this layer
>>>>                 */
>>>> +            assert(ret & BDRV_BLOCK_EOF);
>>>>                *pnum = bytes;
>>>> +            if (file) {
>>>> +                *file = p;
>>>> +            }
>>>> +            return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;
>>>
>>> You don't add BDRV_BLOCK_EOF to the return code here ?
>>
>> No we shouldn't, as this is the end of backing file when the top layer
>> is larger.
> 
> Ok, but maybe the original request also reaches EOF on the top layer.
> 
> An example that does not actually involve short backing files: let's say
> that the size of the active image is 1MB and the backing file is 2MB.
> 
> We do 'write -z 960k 63k', that zeroes the last cluster minus a 1KB
> tail, so qcow2_co_pwrite_zeroes() calls is_zero() to check if that last
> 1KB already contains zeroes.
> 
> bdrv_co_block_status_above() on the top layer returns BDRV_BLOCK_EOF: no
> allocation, no zeros, we simply reached EOF. So we go to the backing
> image to see what's there. This is also unallocated, there's no backing
> file this time and want_zero is set, so this returns BDRV_BLOCK_ZERO.
> However the backing file is longer so bdrv_co_block_status() does not
> return BDRV_BLOCK_EOF this time.
> 
> If the backing file would have been the same size (1MB) we would have
> BDRV_BLOCK_ZERO | BDRV_BLOCK_EOF, but if it's longer or (with your
> patch) shorter then BDRV_BLOCK_EOF disappears.
> 
> Now, I don't see anyone else using BDRV_BLOCK_EOF for anything so this
> does not have any practical effect at the moment, but is this worth
> fixing?.

That's the point of course, I'll fix.

So, if we get EOF on top layer, we should add it to final ret anyway, regardless of backing chain statuses.

> 
>>>> +        res = bdrv_block_status_above(bs, NULL, offset, bytes, &nr, NULL, NULL);
>>>> +        offset += nr;
>>>> +        bytes -= nr;
>>>> +    } while (res >= 0 && (res & BDRV_BLOCK_ZERO) && nr && bytes);
>>>
>>> About this last "... && nr && bytes", I think 'nr' already implies
>>> 'bytes', maybe you want to use an assertion instead?
>>
>> No, on the last iteration, bytes would be 0 and nr is a last
>> chunk. So, if we check only nr, we'll do one extra call of
>> bdrv_block_status_above with bytes=0, I don't want do it.
> 
> You're right !
> 
> Berto
> 


-- 
Best regards,
Vladimir

Re: [PATCH v5 0/5] fix & merge block_status_above and is_allocated_above

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Wed, Jun 10, 2020 at 03:04:21PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> v5: rebase on coroutine-wrappers series, 02 changed correspondingly
> 
> Based on series "[PATCH v7 0/7] coroutines: generate wrapper code", or
> in other words:
> Based-on: <20200610100336.23451-1-vsementsov@virtuozzo.com>

Hi Vladimir,
Please rebase this series and the coroutine wrapper series onto
qemu.git/master so the meson build system change is resolved.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 0/5] fix & merge block_status_above and is_allocated_above

[Vladimir Sementsov-Ogievskiy]

14.09.2020 16:06, Stefan Hajnoczi wrote:
> On Wed, Jun 10, 2020 at 03:04:21PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> v5: rebase on coroutine-wrappers series, 02 changed correspondingly
>>
>> Based on series "[PATCH v7 0/7] coroutines: generate wrapper code", or
>> in other words:
>> Based-on: <20200610100336.23451-1-vsementsov@virtuozzo.com>
> 
> Hi Vladimir,
> Please rebase this series and the coroutine wrapper series onto
> qemu.git/master so the meson build system change is resolved.
> 

Will do this week.

-- 
Best regards,
Vladimir