From 087f2fb3763fd85082fb09ba03ec66ff1d3f5cd7 Mon Sep 17 00:00:00 2001 From: Eric Blake Date: Fri, 3 Dec 2021 17:15:27 -0600 Subject: qemu-io: Utilize 64-bit status during map The block layer has supported 64-bit block status from drivers since commit 86a3d5c688 ("block: Add .bdrv_co_block_status() callback", v2.12) and friends, with individual driver callbacks responsible for capping things where necessary. Artificially capping things below 2G in the qemu-io 'map' command, added in commit d6a644bbfe ("block: Make bdrv_is_allocated() byte-based", v2.10) is thus no longer necessary. One way to test this is with qemu-nbd as server on a raw file larger than 4G (the entire file should show as allocated), plus 'qemu-io -f raw -c map nbd://localhost --trace=nbd_\*' as client. Prior to this patch, the NBD_CMD_BLOCK_STATUS requests are fragmented at 0x7ffffe00 distances; with this patch, the fragmenting changes to 0x7fffffff (since the NBD protocol is currently still limited to 32-bit transactions - see block/nbd.c:nbd_client_co_block_status). Then in later patches, once I add an NBD extension for a 64-bit block status, the same map command completes with just one NBD_CMD_BLOCK_STATUS. Signed-off-by: Eric Blake Message-Id: <20211203231539.3900865-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy --- qemu-io-cmds.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) (limited to 'qemu-io-cmds.c') diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c index 46593d632d..954955c12f 100644 --- a/qemu-io-cmds.c +++ b/qemu-io-cmds.c @@ -1993,11 +1993,9 @@ static int map_is_allocated(BlockDriverState *bs, int64_t offset, int64_t bytes, int64_t *pnum) { int64_t num; - int num_checked; int ret, firstret; - num_checked = MIN(bytes, BDRV_REQUEST_MAX_BYTES); - ret = bdrv_is_allocated(bs, offset, num_checked, &num); + ret = bdrv_is_allocated(bs, offset, bytes, &num); if (ret < 0) { return ret; } @@ -2009,8 +2007,7 @@ static int map_is_allocated(BlockDriverState *bs, int64_t offset, offset += num; bytes -= num; - num_checked = MIN(bytes, BDRV_REQUEST_MAX_BYTES); - ret = bdrv_is_allocated(bs, offset, num_checked, &num); + ret = bdrv_is_allocated(bs, offset, bytes, &num); if (ret == firstret && num) { *pnum += num; } else { -- cgit 1.4.1 From 395aecd037dc35d110b8e1e8cc7d20c1082894b5 Mon Sep 17 00:00:00 2001 From: Eric Blake Date: Fri, 3 Dec 2021 17:15:28 -0600 Subject: qemu-io: Allow larger write zeroes under no fallback When writing zeroes can fall back to a slow write, permitting an overly large request can become an amplification denial of service attack in triggering a large amount of work from a small request. But the whole point of the no fallback flag is to quickly determine if writing an entire device to zero can be done quickly (such as when it is already known that the device started with zero contents); in those cases, artificially capping things at 2G in qemu-io itself doesn't help us. Signed-off-by: Eric Blake Message-Id: <20211203231539.3900865-4-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy --- qemu-io-cmds.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'qemu-io-cmds.c') diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c index 954955c12f..45a9570933 100644 --- a/qemu-io-cmds.c +++ b/qemu-io-cmds.c @@ -603,10 +603,6 @@ static int do_co_pwrite_zeroes(BlockBackend *blk, int64_t offset, .done = false, }; - if (bytes > INT_MAX) { - return -ERANGE; - } - co = qemu_coroutine_create(co_pwrite_zeroes_entry, &data); bdrv_coroutine_enter(blk_bs(blk), co); while (!data.done) { @@ -1160,8 +1156,9 @@ static int write_f(BlockBackend *blk, int argc, char **argv) if (count < 0) { print_cvtnum_err(count, argv[optind]); return count; - } else if (count > BDRV_REQUEST_MAX_BYTES) { - printf("length cannot exceed %" PRIu64 ", given %s\n", + } else if (count > BDRV_REQUEST_MAX_BYTES && + !(flags & BDRV_REQ_NO_FALLBACK)) { + printf("length cannot exceed %" PRIu64 " without -n, given %s\n", (uint64_t)BDRV_REQUEST_MAX_BYTES, argv[optind]); return -EINVAL; } -- cgit 1.4.1