Skip to content
  • Vladimir Sementsov-Ogievskiy's avatar
    5ae07b14
    block/io: support int64_t bytes in bdrv_co_do_pwrite_zeroes() · 5ae07b14
    Vladimir Sementsov-Ogievskiy authored
    
    
    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: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Message-Id: <20201211183934.169161-11-vsementsov@virtuozzo.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    5ae07b14
    block/io: support int64_t bytes in bdrv_co_do_pwrite_zeroes()
    Vladimir Sementsov-Ogievskiy authored
    
    
    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: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Message-Id: <20201211183934.169161-11-vsementsov@virtuozzo.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
Loading