qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v4 13/16] block/io: support int64_t bytes in bdrv_aligned_pre


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v4 13/16] block/io: support int64_t bytes in bdrv_aligned_preadv()
Date: Sat, 23 Jan 2021 17:34:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

22.01.2021 19:54, Eric Blake wrote:
On 12/11/20 12:39 PM, Vladimir Sementsov-Ogievskiy wrote:
We are generally moving to int64_t for both offset and bytes parameters
on all io paths.

Main motivation is realization of 64-bit write_zeroes operation for
fast zeroing large disk chunks, up to the whole disk.

We chose signed type, to be consistent with off_t (which is signed) and
with possibility for signed return type (where negative value means
error).

So, prepare bdrv_aligned_preadv() now.

Make byte variable in bdrv_padding_rmw_read() int64_t, as it defined
only to be passed to bdrv_aligned_preadv().

Reads awkwardly, how about:

Make the byte variable in bdrv_padding_rmw_read() int64_t, as it is only
used for pass-through to bdrv_aligned_preadv().

and also s/byte/bytes/



All bdrv_aligned_preadv() callers are safe as type is widening. Let's
look inside:

  - add a new-style assertion that request is good.
  - callees bdrv_is_allocated(), bdrv_co_do_copy_on_readv() supports
    int64_t bytes
  - conversion of bytes_remaining is OK, as we never has requests

have

    overflowing BDRV_MAX_LENGTH
  - looping through bytes_remaining is ok, num is updated to int64_t
    - for bdrv_driver_preadv we have same limit of max_transfer
    - qemu_iovec_memset is OK, as bytes+qiov_offset should not overflow
      qiov->size anyway (thanks to bdrv_check_qiov_request())

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
  block/io.c | 9 +++++----
  1 file changed, 5 insertions(+), 4 deletions(-)


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



--
Best regards,
Vladimir



reply via email to

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