[Top][All Lists]

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

Re: [PATCH v4 10/16] block/io: support int64_t bytes in bdrv_co_do_pwrit

From: Eric Blake
Subject: Re: [PATCH v4 10/16] block/io: support int64_t bytes in bdrv_co_do_pwrite_zeroes()
Date: Fri, 22 Jan 2021 10:18:52 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

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_co_do_pwrite_zeroes() now.
> Callers are safe, as converting int to int64_t is safe. Concentrate on
> 'bytes' usage in the function (thx to Eric Blake):
>     compute 'int tail' via % 'int alignment' - safe
>     fragmentation loop 'int num' - still fragments with a cap on
>       max_transfer
>     use of 'num' within the loop
>     MIN(bytes, max_transfer) as well as %alignment - still works, so
>          calculations in if (head) {} are safe
>     clamp size by 'int max_write_zeroes' - safe
>     drv->bdrv_co_pwrite_zeroes(int) - safe because of clamping
>     clamp size by 'int max_transfer' - safe
>     buf allocation is still clamped to max_transfer
>     qemu_iovec_init_buf(size_t) - safe because of clamping
>     bdrv_driver_pwritev(uint64_t) - safe
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>  block/io.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)

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

And thanks for including the gist of my previous audit - that greatly
speeds things up this time through. ;)

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

reply via email to

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