blk_check_bytes_request is called from blk_co_do_preadv,
blk_co_do_pwritev_part, blk_co_do_pdiscard and blk_co_copy_range
before (maybe) calling throttle_group_co_io_limits_intercept() (which
has int64_t argument) and then calling corresponding bdrv_co_ function.
bdrv_co_ functions are OK with int64_t bytes as well.

So dropping the check for INT_MAX we just get same restrictions as in
bdrv_ layer: discard and write-zeroes goes through
bdrv_check_qiov_request() and are allowed to be 64bit. Other requests
go through bdrv_check_request32() and still restricted by INT_MAX
boundary.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 block/block-backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/block-backend.c b/block/block-backend.c
index e2b363ff63..21d8e88311 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -1166,7 +1166,7 @@ static int blk_check_byte_request(BlockBackend *blk, int64_t offset,
 {
     int64_t len;
 
-    if (bytes < 0 || bytes > INT_MAX) {
+    if (bytes < 0) {
         return -EIO;
     }
 
-- 
2.31.1

On Wed, Oct 06, 2021 at 03:17:18PM +0200, Vladimir Sementsov-Ogievskiy wrote:
> blk_check_bytes_request is called from blk_co_do_preadv,
> blk_co_do_pwritev_part, blk_co_do_pdiscard and blk_co_copy_range
> before (maybe) calling throttle_group_co_io_limits_intercept() (which
> has int64_t argument) and then calling corresponding bdrv_co_ function.
> bdrv_co_ functions are OK with int64_t bytes as well.
> 
> So dropping the check for INT_MAX we just get same restrictions as in
> bdrv_ layer: discard and write-zeroes goes through
> bdrv_check_qiov_request() and are allowed to be 64bit. Other requests
> go through bdrv_check_request32() and still restricted by INT_MAX
> boundary.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>  block/block-backend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Deceptively short, but this is the one where a mistake would hurt.

Thankfully, I agree with your analysis that the call stack is still
checking 32-bit limits on read/write, and that discard/zero requests
can now go up to 63-bit sizing if everything else in the call stack is
ready; plus the fact that we are careful both in our drivers to
document actual limits (whether 32-bit or even smaller), and in the
block code to honor those limits (breaking larger requests into chunks
before reaching this far).

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org