Series comparison

-[Qemu-devel] [PULL 0/2] Block patches
+[PULL for-6.1 0/3] Block patches
-The following changes since commit 36f87b4513373b3cd79c87c9197d17face95d4ac:
+The following changes since commit 3521ade3510eb5cefb2e27a101667f25dad89935:
-  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170630' into staging (2017-06-30 11:58:49 +0100)
+  Merge remote-tracking branch 'remotes/thuth-gitlab/tags/pull-request-2021-07-29' into staging (2021-07-29 13:17:20 +0100)
-are available in the git repository at:
+are available in the Git repository at:
-  git://github.com/famz/qemu.git tags/block-pull-request
+  https://gitlab.com/stefanha/qemu.git tags/block-pull-request
-for you to fetch changes up to c61e684e44272f2acb2bef34cf2aa234582a73a9:
+for you to fetch changes up to cc8eecd7f105a1dff5876adeb238a14696061a4a:
-  block: Exploit BDRV_BLOCK_EOF for larger zero blocks (2017-06-30 21:48:06 +0800)
+  MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver (2021-07-29 17:17:34 +0100)
 ----------------------------------------------------------------
 Pull request
 The main fix here is for io_uring. Spurious -EAGAIN errors can happen and the
 request needs to be resubmitted.
 The MAINTAINERS changes carry no risk and we might as well include them in QEMU
 .1.
 ----------------------------------------------------------------
-Hi Peter,
+Fabian Ebner (1):
   block/io_uring: resubmit when result is -EAGAIN
-Here are Eric Blake's enhancement to block layer API. Thanks!
+Philippe Mathieu-Daudé (1):
   MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver
-----------------------------------------------------------------
+Stefano Garzarella (1):
   MAINTAINERS: add Stefano Garzarella as io_uring reviewer
-Eric Blake (2):
+ MAINTAINERS      |  2 ++
-  block: Add BDRV_BLOCK_EOF to bdrv_get_block_status()
+ block/io_uring.c | 16 +++++++++++++++-
-  block: Exploit BDRV_BLOCK_EOF for larger zero blocks
+files changed, 17 insertions(+), 1 deletion(-)
  block/io.c                 | 42 +++++++++++++++++++++++++++++++++---------
  include/block/block.h      |  2 ++
  tests/qemu-iotests/154     |  4 ----
  tests/qemu-iotests/154.out | 12 ++++++------
 files changed, 41 insertions(+), 19 deletions(-)
 --
-.9.4
+.31.1

-New patch
+[PULL for-6.1 1/3] MAINTAINERS: add Stefano Garzarella as io_uring reviewer
+From: Stefano Garzarella <sgarzare@redhat.com>
+I've been working with io_uring for a while so I'd like to help
+with reviews.
+Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
+Message-Id: <20210728131515.131045-1-sgarzare@redhat.com>
+Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
+---
+ MAINTAINERS | 1 +
+file changed, 1 insertion(+)
+diff --git a/MAINTAINERS b/MAINTAINERS
+index XXXXXXX..XXXXXXX 100644
+--- a/MAINTAINERS
++++ b/MAINTAINERS
+@@ -XXX,XX +XXX,XX @@ Linux io_uring
+ M: Aarushi Mehta <mehta.aaru20@gmail.com>
+ M: Julia Suvorova <jusual@redhat.com>
+ M: Stefan Hajnoczi <stefanha@redhat.com>
++R: Stefano Garzarella <sgarzare@redhat.com>
+ L: qemu-block@nongnu.org
+ S: Maintained
+ F: block/io_uring.c
+--
+.31.1

-[Qemu-devel] [PULL 2/2] block: Exploit BDRV_BLOCK_EOF for larger zero blocks
+[PULL for-6.1 2/3] block/io_uring: resubmit when result is -EAGAIN
-From: Eric Blake <eblake@redhat.com>
+From: Fabian Ebner <f.ebner@proxmox.com>
-When we have a BDS with unallocated clusters, but asking the status
+Linux SCSI can throw spurious -EAGAIN in some corner cases in its
-of its underlying bs->file or backing layer encounters an end-of-file
+completion path, which will end up being the result in the completed
-condition, we know that the rest of the unallocated area will read as
+io_uring request.
 zeroes.  However, pre-patch, this required two separate calls to
 bdrv_get_block_status(), as the first call stops at the point where
 the underlying file ends.  Thanks to BDRV_BLOCK_EOF, we can now widen
 the results of the primary status if the secondary status already
 includes BDRV_BLOCK_ZERO.
-In turn, this fixes a TODO mentioned in iotest 154, where we can now
+Resubmitting such requests should allow block jobs to complete, even
-see that all sectors in a partial cluster at the end of a file read
+if such spurious errors are encountered.
 as zero when coupling the shorter backing file's status along with our
 knowledge that the remaining sectors came from an unallocated cluster.
-Also, note that the loop in bdrv_co_get_block_status_above() had an
+Co-authored-by: Stefan Hajnoczi <stefanha@gmail.com>
-inefficent exit: in cases where the active layer sets BDRV_BLOCK_ZERO
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
-but does NOT set BDRV_BLOCK_ALLOCATED (namely, where we know we read
+Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
-zeroes merely because our unallocated clusters lie beyond the backing
+Message-id: 20210729091029.65369-1-f.ebner@proxmox.com
-file's shorter length), we still ended up probing the backing layer
+Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
-even though we already had a good answer.
+---
  block/io_uring.c | 16 +++++++++++++++-
 file changed, 15 insertions(+), 1 deletion(-)
-Signed-off-by: Eric Blake <eblake@redhat.com>
+diff --git a/block/io_uring.c b/block/io_uring.c
-Message-Id: <20170505021500.19315-3-eblake@redhat.com>
+index XXXXXXX..XXXXXXX 100644
-Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
+--- a/block/io_uring.c
-Signed-off-by: Fam Zheng <famz@redhat.com>
++++ b/block/io_uring.c
----
+@@ -XXX,XX +XXX,XX @@ static void luring_process_completions(LuringState *s)
- block/io.c                 | 27 ++++++++++++++++++++++-----
+         total_bytes = ret + luringcb->total_read;
- tests/qemu-iotests/154     |  4 ----
- tests/qemu-iotests/154.out | 12 ++++++------
+         if (ret < 0) {
-files changed, 28 insertions(+), 15 deletions(-)
+-            if (ret == -EINTR) {
 +            /*
 +             * Only writev/readv/fsync requests on regular files or host block
 +             * devices are submitted. Therefore -EAGAIN is not expected but it's
 +             * known to happen sometimes with Linux SCSI. Submit again and hope
 +             * the request completes successfully.
 +             *
 +             * For more information, see:
 +             * https://lore.kernel.org/io-uring/20210727165811.284510-3-axboe@kernel.dk/T/#u
 +             *
 +             * If the code is changed to submit other types of requests in the
 +             * future, then this workaround may need to be extended to deal with
 +             * genuine -EAGAIN results that should not be resubmitted
 +             * immediately.
 +             */
 +            if (ret == -EINTR || ret == -EAGAIN) {
                  luring_resubmit(s, luringcb);
                  continue;
              }
 --
 .31.1
-diff --git a/block/io.c b/block/io.c
-index XXXXXXX..XXXXXXX 100644
---- a/block/io.c
-+++ b/block/io.c
-@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
-             /* Ignore errors.  This is just providing extra information, it
-              * is useful but not necessary.
-              */
--            if (!file_pnum) {
--                /* !file_pnum indicates an offset at or beyond the EOF; it is
--                 * perfectly valid for the format block driver to point to such
--                 * offsets, so catch it and mark everything as zero */
-+            if (ret2 & BDRV_BLOCK_EOF &&
-+                (!file_pnum || ret2 & BDRV_BLOCK_ZERO)) {
-+                /*
-+                 * It is valid for the format block driver to read
-+                 * beyond the end of the underlying file's current
-+                 * size; such areas read as zero.
-+                 */
-                 ret |= BDRV_BLOCK_ZERO;
-             } else {
-                 /* Limit request to the range reported by the protocol driver */
-@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status_above(BlockDriverState *bs,
- {
-     BlockDriverState *p;
-     int64_t ret = 0;
-+    bool first = true;
-     assert(bs != base);
-     for (p = bs; p != base; p = backing_bs(p)) {
-         ret = bdrv_co_get_block_status(p, sector_num, nb_sectors, pnum, file);
--        if (ret < 0 || ret & BDRV_BLOCK_ALLOCATED) {
-+        if (ret < 0) {
-+            break;
-+        }
-+        if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
-+            /*
-+             * 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.
-+             */
-+            *pnum = nb_sectors;
-+        }
-+        if (ret & (BDRV_BLOCK_ZERO | BDRV_BLOCK_DATA)) {
-             break;
-         }
-         /* [sector_num, pnum] unallocated on this layer, which could be only
-          * the first part of [sector_num, nb_sectors].  */
-         nb_sectors = MIN(nb_sectors, *pnum);
-+        first = false;
-     }
-     return ret;
- }
-diff --git a/tests/qemu-iotests/154 b/tests/qemu-iotests/154
-index XXXXXXX..XXXXXXX 100755
---- a/tests/qemu-iotests/154
-+++ b/tests/qemu-iotests/154
-@@ -XXX,XX +XXX,XX @@ $QEMU_IO -c "alloc $size 2048" "$TEST_IMG" | _filter_qemu_io
- $QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
- # Repeat with backing file holding unallocated cluster.
--# TODO: Note that this forces an allocation, because we aren't yet able to
--# quickly detect that reads beyond EOF of the backing file are always zero
- CLUSTER_SIZE=2048 TEST_IMG="$TEST_IMG.base" _make_test_img $((size + 1024))
- # Write at the front: sector-wise, the request is:
-@@ -XXX,XX +XXX,XX @@ $QEMU_IO -c "alloc $size 2048" "$TEST_IMG" | _filter_qemu_io
- $QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
- # Repeat with backing file holding zero'd cluster
--# TODO: Note that this forces an allocation, because we aren't yet able to
--# quickly detect that reads beyond EOF of the backing file are always zero
- $QEMU_IO -c "write -z $size 512" "$TEST_IMG.base" | _filter_qemu_io
- # Write at the front: sector-wise, the request is:
-diff --git a/tests/qemu-iotests/154.out b/tests/qemu-iotests/154.out
-index XXXXXXX..XXXXXXX 100644
---- a/tests/qemu-iotests/154.out
-+++ b/tests/qemu-iotests/154.out
-@@ -XXX,XX +XXX,XX @@ wrote 512/512 bytes at offset 134217728
-bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-/2048 bytes allocated at offset 128 MiB
- [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
--{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
-+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
- wrote 512/512 bytes at offset 134219264
-bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-/2048 bytes allocated at offset 128 MiB
- [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
--{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
-+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
- wrote 1024/1024 bytes at offset 134218240
-KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-/2048 bytes allocated at offset 128 MiB
- [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
--{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
-+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
- wrote 2048/2048 bytes at offset 134217728
-KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-@@ -XXX,XX +XXX,XX @@ wrote 512/512 bytes at offset 134217728
-bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-/2048 bytes allocated at offset 128 MiB
- [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
--{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
-+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
- wrote 512/512 bytes at offset 134219264
-bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-/2048 bytes allocated at offset 128 MiB
- [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
--{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
-+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
- wrote 1024/1024 bytes at offset 134218240
-KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-/2048 bytes allocated at offset 128 MiB
- [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
--{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
-+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
- wrote 2048/2048 bytes at offset 134217728
-KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
---
-.9.4

-[Qemu-devel] [PULL 1/2] block: Add BDRV_BLOCK_EOF to bdrv_get_block_status()
+[PULL for-6.1 3/3] MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver
-From: Eric Blake <eblake@redhat.com>
+From: Philippe Mathieu-Daudé <philmd@redhat.com>
-Just as the block layer already sets BDRV_BLOCK_ALLOCATED as a
+I'm interested in following the activity around the NVMe bdrv.
 shortcut for subsequent operations, there are also some optimizations
 that are made easier if we can quickly tell that *pnum will advance
 us to the end of a file, via a new BDRV_BLOCK_EOF which gets set
 by the block layer.
-This just plumbs up the new bit; subsequent patches will make use
+Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
-of it.
+Message-id: 20210728183340.2018313-1-philmd@redhat.com
 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
 ---
  MAINTAINERS | 1 +
 file changed, 1 insertion(+)
-Signed-off-by: Eric Blake <eblake@redhat.com>
+diff --git a/MAINTAINERS b/MAINTAINERS
-Message-Id: <20170505021500.19315-2-eblake@redhat.com>
+index XXXXXXX..XXXXXXX 100644
-Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
+--- a/MAINTAINERS
-Signed-off-by: Fam Zheng <famz@redhat.com>
++++ b/MAINTAINERS
----
+@@ -XXX,XX +XXX,XX @@ F: block/null.c
- block/io.c            | 15 +++++++++++----
+ NVMe Block Driver
- include/block/block.h |  2 ++
+ M: Stefan Hajnoczi <stefanha@redhat.com>
-files changed, 13 insertions(+), 4 deletions(-)
+ R: Fam Zheng <fam@euphon.net>
 +R: Philippe Mathieu-Daudé <philmd@redhat.com>
  L: qemu-block@nongnu.org
  S: Supported
  F: block/nvme*
 --
 .31.1
-diff --git a/block/io.c b/block/io.c
-index XXXXXXX..XXXXXXX 100644
---- a/block/io.c
-+++ b/block/io.c
-@@ -XXX,XX +XXX,XX @@ typedef struct BdrvCoGetBlockStatusData {
-  * Drivers not implementing the functionality are assumed to not support
-  * backing files, hence all their sectors are reported as allocated.
-  *
-- * If 'sector_num' is beyond the end of the disk image the return value is 0
-- * and 'pnum' is set to 0.
-+ * If 'sector_num' is beyond the end of the disk image the return value is
-+ * BDRV_BLOCK_EOF and 'pnum' is set to 0.
-  *
-  * 'pnum' is set to the number of sectors (including and immediately following
-  * the specified sector) that are known to be in the same
-  * allocated/unallocated state.
-  *
-  * 'nb_sectors' is the max value 'pnum' should be set to.  If nb_sectors goes
-- * beyond the end of the disk image it will be clamped.
-+ * beyond the end of the disk image it will be clamped; if 'pnum' is set to
-+ * the end of the image, then the returned value will include BDRV_BLOCK_EOF.
-  *
-  * If returned value is positive and BDRV_BLOCK_OFFSET_VALID bit is set, 'file'
-  * points to the BDS which the sector range is allocated in.
-@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
-     if (sector_num >= total_sectors) {
-         *pnum = 0;
--        return 0;
-+        return BDRV_BLOCK_EOF;
-     }
-     n = total_sectors - sector_num;
-@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
-     if (!bs->drv->bdrv_co_get_block_status) {
-         *pnum = nb_sectors;
-         ret = BDRV_BLOCK_DATA | BDRV_BLOCK_ALLOCATED;
-+        if (sector_num + nb_sectors == total_sectors) {
-+            ret |= BDRV_BLOCK_EOF;
-+        }
-         if (bs->drv->protocol_name) {
-             ret |= BDRV_BLOCK_OFFSET_VALID | (sector_num * BDRV_SECTOR_SIZE);
-         }
-@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
- out:
-     bdrv_dec_in_flight(bs);
-+    if (ret >= 0 && sector_num + *pnum == total_sectors) {
-+        ret |= BDRV_BLOCK_EOF;
-+    }
-     return ret;
- }
-diff --git a/include/block/block.h b/include/block/block.h
-index XXXXXXX..XXXXXXX 100644
---- a/include/block/block.h
-+++ b/include/block/block.h
-@@ -XXX,XX +XXX,XX @@ typedef struct HDGeometry {
-  * BDRV_BLOCK_OFFSET_VALID: an associated offset exists for accessing raw data
-  * BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
-  *                       layer (short for DATA || ZERO), set by block layer
-+ * BDRV_BLOCK_EOF: the returned pnum covers through end of file for this layer
-  *
-  * Internal flag:
-  * BDRV_BLOCK_RAW: used internally to indicate that the request was
-@@ -XXX,XX +XXX,XX @@ typedef struct HDGeometry {
- #define BDRV_BLOCK_OFFSET_VALID 0x04
- #define BDRV_BLOCK_RAW          0x08
- #define BDRV_BLOCK_ALLOCATED    0x10
-+#define BDRV_BLOCK_EOF          0x20
- #define BDRV_BLOCK_OFFSET_MASK  BDRV_SECTOR_MASK
- typedef QSIMPLEQ_HEAD(BlockReopenQueue, BlockReopenQueueEntry) BlockReopenQueue;
---
-.9.4

The following changes since commit 36f87b4513373b3cd79c87c9197d17face95d4ac:

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170630' into staging (2017-06-30 11:58:49 +0100)

are available in the git repository at:

git://github.com/famz/qemu.git tags/block-pull-request

for you to fetch changes up to c61e684e44272f2acb2bef34cf2aa234582a73a9:

block: Exploit BDRV_BLOCK_EOF for larger zero blocks (2017-06-30 21:48:06 +0800)

----------------------------------------------------------------

Hi Peter,

Here are Eric Blake's enhancement to block layer API. Thanks!

----------------------------------------------------------------

Eric Blake (2):
  block: Add BDRV_BLOCK_EOF to bdrv_get_block_status()
  block: Exploit BDRV_BLOCK_EOF for larger zero blocks

block/io.c                 | 42 +++++++++++++++++++++++++++++++++---------
 include/block/block.h      |  2 ++
 tests/qemu-iotests/154     |  4 ----
 tests/qemu-iotests/154.out | 12 ++++++------
 4 files changed, 41 insertions(+), 19 deletions(-)

-- 
2.9.4

From: Eric Blake <eblake@redhat.com>

Just as the block layer already sets BDRV_BLOCK_ALLOCATED as a
shortcut for subsequent operations, there are also some optimizations
that are made easier if we can quickly tell that *pnum will advance
us to the end of a file, via a new BDRV_BLOCK_EOF which gets set
by the block layer.

This just plumbs up the new bit; subsequent patches will make use
of it.

Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20170505021500.19315-2-eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
---
 block/io.c            | 15 +++++++++++----
 include/block/block.h |  2 ++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/block/io.c b/block/io.c
index XXXXXXX..XXXXXXX 100644
--- a/block/io.c
+++ b/block/io.c
@@ -XXX,XX +XXX,XX @@ typedef struct BdrvCoGetBlockStatusData {
  * Drivers not implementing the functionality are assumed to not support
  * backing files, hence all their sectors are reported as allocated.
  *
- * If 'sector_num' is beyond the end of the disk image the return value is 0
- * and 'pnum' is set to 0.
+ * If 'sector_num' is beyond the end of the disk image the return value is
+ * BDRV_BLOCK_EOF and 'pnum' is set to 0.
  *
  * 'pnum' is set to the number of sectors (including and immediately following
  * the specified sector) that are known to be in the same
  * allocated/unallocated state.
  *
  * 'nb_sectors' is the max value 'pnum' should be set to.  If nb_sectors goes
- * beyond the end of the disk image it will be clamped.
+ * beyond the end of the disk image it will be clamped; if 'pnum' is set to
+ * the end of the image, then the returned value will include BDRV_BLOCK_EOF.
  *
  * If returned value is positive and BDRV_BLOCK_OFFSET_VALID bit is set, 'file'
  * points to the BDS which the sector range is allocated in.
@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
 
     if (sector_num >= total_sectors) {
         *pnum = 0;
-        return 0;
+        return BDRV_BLOCK_EOF;
     }
 
     n = total_sectors - sector_num;
@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
     if (!bs->drv->bdrv_co_get_block_status) {
         *pnum = nb_sectors;
         ret = BDRV_BLOCK_DATA | BDRV_BLOCK_ALLOCATED;
+        if (sector_num + nb_sectors == total_sectors) {
+            ret |= BDRV_BLOCK_EOF;
+        }
         if (bs->drv->protocol_name) {
             ret |= BDRV_BLOCK_OFFSET_VALID | (sector_num * BDRV_SECTOR_SIZE);
         }
@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
 
 out:
     bdrv_dec_in_flight(bs);
+    if (ret >= 0 && sector_num + *pnum == total_sectors) {
+        ret |= BDRV_BLOCK_EOF;
+    }
     return ret;
 }
 
diff --git a/include/block/block.h b/include/block/block.h
index XXXXXXX..XXXXXXX 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -XXX,XX +XXX,XX @@ typedef struct HDGeometry {
  * BDRV_BLOCK_OFFSET_VALID: an associated offset exists for accessing raw data
  * BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
  *                       layer (short for DATA || ZERO), set by block layer
+ * BDRV_BLOCK_EOF: the returned pnum covers through end of file for this layer
  *
  * Internal flag:
  * BDRV_BLOCK_RAW: used internally to indicate that the request was
@@ -XXX,XX +XXX,XX @@ typedef struct HDGeometry {
 #define BDRV_BLOCK_OFFSET_VALID 0x04
 #define BDRV_BLOCK_RAW          0x08
 #define BDRV_BLOCK_ALLOCATED    0x10
+#define BDRV_BLOCK_EOF          0x20
 #define BDRV_BLOCK_OFFSET_MASK  BDRV_SECTOR_MASK
 
 typedef QSIMPLEQ_HEAD(BlockReopenQueue, BlockReopenQueueEntry) BlockReopenQueue;
-- 
2.9.4

From: Eric Blake <eblake@redhat.com>

When we have a BDS with unallocated clusters, but asking the status
of its underlying bs->file or backing layer encounters an end-of-file
condition, we know that the rest of the unallocated area will read as
zeroes.  However, pre-patch, this required two separate calls to
bdrv_get_block_status(), as the first call stops at the point where
the underlying file ends.  Thanks to BDRV_BLOCK_EOF, we can now widen
the results of the primary status if the secondary status already
includes BDRV_BLOCK_ZERO.

In turn, this fixes a TODO mentioned in iotest 154, where we can now
see that all sectors in a partial cluster at the end of a file read
as zero when coupling the shorter backing file's status along with our
knowledge that the remaining sectors came from an unallocated cluster.

Also, note that the loop in bdrv_co_get_block_status_above() had an
inefficent exit: in cases where the active layer sets BDRV_BLOCK_ZERO
but does NOT set BDRV_BLOCK_ALLOCATED (namely, where we know we read
zeroes merely because our unallocated clusters lie beyond the backing
file's shorter length), we still ended up probing the backing layer
even though we already had a good answer.

Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20170505021500.19315-3-eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
---
 block/io.c                 | 27 ++++++++++++++++++++++-----
 tests/qemu-iotests/154     |  4 ----
 tests/qemu-iotests/154.out | 12 ++++++------
 3 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/block/io.c b/block/io.c
index XXXXXXX..XXXXXXX 100644
--- a/block/io.c
+++ b/block/io.c
@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
             /* Ignore errors.  This is just providing extra information, it
              * is useful but not necessary.
              */
-            if (!file_pnum) {
-                /* !file_pnum indicates an offset at or beyond the EOF; it is
-                 * perfectly valid for the format block driver to point to such
-                 * offsets, so catch it and mark everything as zero */
+            if (ret2 & BDRV_BLOCK_EOF &&
+                (!file_pnum || ret2 & BDRV_BLOCK_ZERO)) {
+                /*
+                 * It is valid for the format block driver to read
+                 * beyond the end of the underlying file's current
+                 * size; such areas read as zero.
+                 */
                 ret |= BDRV_BLOCK_ZERO;
             } else {
                 /* Limit request to the range reported by the protocol driver */
@@ -XXX,XX +XXX,XX @@ static int64_t coroutine_fn bdrv_co_get_block_status_above(BlockDriverState *bs,
 {
     BlockDriverState *p;
     int64_t ret = 0;
+    bool first = true;
 
     assert(bs != base);
     for (p = bs; p != base; p = backing_bs(p)) {
         ret = bdrv_co_get_block_status(p, sector_num, nb_sectors, pnum, file);
-        if (ret < 0 || ret & BDRV_BLOCK_ALLOCATED) {
+        if (ret < 0) {
+            break;
+        }
+        if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
+            /*
+             * 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.
+             */
+            *pnum = nb_sectors;
+        }
+        if (ret & (BDRV_BLOCK_ZERO | BDRV_BLOCK_DATA)) {
             break;
         }
         /* [sector_num, pnum] unallocated on this layer, which could be only
          * the first part of [sector_num, nb_sectors].  */
         nb_sectors = MIN(nb_sectors, *pnum);
+        first = false;
     }
     return ret;
 }
diff --git a/tests/qemu-iotests/154 b/tests/qemu-iotests/154
index XXXXXXX..XXXXXXX 100755
--- a/tests/qemu-iotests/154
+++ b/tests/qemu-iotests/154
@@ -XXX,XX +XXX,XX @@ $QEMU_IO -c "alloc $size 2048" "$TEST_IMG" | _filter_qemu_io
 $QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
 
 # Repeat with backing file holding unallocated cluster.
-# TODO: Note that this forces an allocation, because we aren't yet able to
-# quickly detect that reads beyond EOF of the backing file are always zero
 CLUSTER_SIZE=2048 TEST_IMG="$TEST_IMG.base" _make_test_img $((size + 1024))
 
 # Write at the front: sector-wise, the request is:
@@ -XXX,XX +XXX,XX @@ $QEMU_IO -c "alloc $size 2048" "$TEST_IMG" | _filter_qemu_io
 $QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
 
 # Repeat with backing file holding zero'd cluster
-# TODO: Note that this forces an allocation, because we aren't yet able to
-# quickly detect that reads beyond EOF of the backing file are always zero
 $QEMU_IO -c "write -z $size 512" "$TEST_IMG.base" | _filter_qemu_io
 
 # Write at the front: sector-wise, the request is:
diff --git a/tests/qemu-iotests/154.out b/tests/qemu-iotests/154.out
index XXXXXXX..XXXXXXX 100644
--- a/tests/qemu-iotests/154.out
+++ b/tests/qemu-iotests/154.out
@@ -XXX,XX +XXX,XX @@ wrote 512/512 bytes at offset 134217728
 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 2048/2048 bytes allocated at offset 128 MiB
 [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
-{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
 wrote 512/512 bytes at offset 134219264
 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 2048/2048 bytes allocated at offset 128 MiB
 [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
-{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
 wrote 1024/1024 bytes at offset 134218240
 1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 2048/2048 bytes allocated at offset 128 MiB
 [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
-{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
 wrote 2048/2048 bytes at offset 134217728
 2 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
@@ -XXX,XX +XXX,XX @@ wrote 512/512 bytes at offset 134217728
 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 2048/2048 bytes allocated at offset 128 MiB
 [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
-{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
 wrote 512/512 bytes at offset 134219264
 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 2048/2048 bytes allocated at offset 128 MiB
 [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
-{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
 wrote 1024/1024 bytes at offset 134218240
 1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 2048/2048 bytes allocated at offset 128 MiB
 [{ "start": 0, "length": 134217728, "depth": 1, "zero": true, "data": false},
-{ "start": 134217728, "length": 2048, "depth": 0, "zero": false, "data": true, "offset": OFFSET}]
+{ "start": 134217728, "length": 2048, "depth": 0, "zero": true, "data": false}]
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134219776 backing_file=TEST_DIR/t.IMGFMT.base
 wrote 2048/2048 bytes at offset 134217728
 2 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-- 
2.9.4

The following changes since commit 3521ade3510eb5cefb2e27a101667f25dad89935:

Merge remote-tracking branch 'remotes/thuth-gitlab/tags/pull-request-2021-07-29' into staging (2021-07-29 13:17:20 +0100)

are available in the Git repository at:

https://gitlab.com/stefanha/qemu.git tags/block-pull-request

for you to fetch changes up to cc8eecd7f105a1dff5876adeb238a14696061a4a:

MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver (2021-07-29 17:17:34 +0100)

----------------------------------------------------------------
Pull request

The main fix here is for io_uring. Spurious -EAGAIN errors can happen and the
request needs to be resubmitted.

The MAINTAINERS changes carry no risk and we might as well include them in QEMU
6.1.

----------------------------------------------------------------

Fabian Ebner (1):
  block/io_uring: resubmit when result is -EAGAIN

Philippe Mathieu-Daudé (1):
  MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver

Stefano Garzarella (1):
  MAINTAINERS: add Stefano Garzarella as io_uring reviewer

MAINTAINERS      |  2 ++
 block/io_uring.c | 16 +++++++++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.31.1

From: Fabian Ebner <f.ebner@proxmox.com>

Linux SCSI can throw spurious -EAGAIN in some corner cases in its
completion path, which will end up being the result in the completed
io_uring request.

Resubmitting such requests should allow block jobs to complete, even
if such spurious errors are encountered.

Co-authored-by: Stefan Hajnoczi <stefanha@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Message-id: 20210729091029.65369-1-f.ebner@proxmox.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 block/io_uring.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/block/io_uring.c b/block/io_uring.c
index XXXXXXX..XXXXXXX 100644
--- a/block/io_uring.c
+++ b/block/io_uring.c
@@ -XXX,XX +XXX,XX @@ static void luring_process_completions(LuringState *s)
         total_bytes = ret + luringcb->total_read;
 
         if (ret < 0) {
-            if (ret == -EINTR) {
+            /*
+             * Only writev/readv/fsync requests on regular files or host block
+             * devices are submitted. Therefore -EAGAIN is not expected but it's
+             * known to happen sometimes with Linux SCSI. Submit again and hope
+             * the request completes successfully.
+             *
+             * For more information, see:
+             * https://lore.kernel.org/io-uring/20210727165811.284510-3-axboe@kernel.dk/T/#u
+             *
+             * If the code is changed to submit other types of requests in the
+             * future, then this workaround may need to be extended to deal with
+             * genuine -EAGAIN results that should not be resubmitted
+             * immediately.
+             */
+            if (ret == -EINTR || ret == -EAGAIN) {
                 luring_resubmit(s, luringcb);
                 continue;
             }
-- 
2.31.1