Re: [Qemu-block] [PATCH v6 12/24] block: Convert bdrv_get_block_status_above() to bytes

[Kevin Wolf]

Am 20.10.2017 um 17:22 hat Eric Blake geschrieben:
> On 10/20/2017 10:03 AM, Kevin Wolf wrote:
> > Am 12.10.2017 um 05:47 hat Eric Blake geschrieben:
> >> We are gradually moving away from sector-based interfaces, towards
> >> byte-based.  In the common case, allocation is unlikely to ever use
> >> values that are not naturally sector-aligned, but it is possible
> >> that byte-based values will let us be more precise about allocation
> >> at the end of an unaligned file that can do byte-based access.
> >>
> 
> >>  int bdrv_block_status(BlockDriverState *bs, int64_t offset, int64_t bytes,
> >>                        int64_t *pnum, int64_t *map, BlockDriverState 
> >> **file)
> >>  {
> >> -    int64_t ret;
> >> -    int n;
> >> -
> >> -    assert(QEMU_IS_ALIGNED(offset | bytes, BDRV_SECTOR_SIZE));
> >> -    assert(pnum);
> >> -    /*
> >> -     * The contract allows us to return pnum smaller than bytes, even
> >> -     * if the next query would see the same status; we truncate the
> >> -     * request to avoid overflowing the driver's 32-bit interface.
> >> -     */
> >> -    bytes = MIN(bytes, BDRV_REQUEST_MAX_BYTES);
> > 
> > Is the limitation to BDRV_REQUEST_MAX_BYTES going away without being
> > replaced by a new one in bdrv_co_block_status()? What protects us now
> > from 32-bit truncation?
> 
> As of this patch, we have this 64-bit-clean call chain:
> bdrv_block_status()
>   bdrv_block_status_above()
>     bdrv_common_block_status_above()
>       bdrv_block_status_above_co_entry()
>         bdrv_co_block_status_above()
>           bdrv_co_block_status()
> 
> which in turn has:
>     /*
>      * The contract allows us to return pnum smaller than bytes, even
>      * if the next query would see the same status; we truncate the
>      * request to avoid overflowing the driver's 32-bit interface.
>      */
>     bytes = MIN(bytes, BDRV_REQUEST_MAX_BYTES);
> 
> added earlier in 8/24.
> 
> At the end of series 3, the truncation prevention is still in place when
> calling into the drivers, per the changes to bdrv_co_block_status() in
> 21/24.

I looked at the final state and missed it because now INT_MAX is used
rather than BDRV_REQUEST_MAX_BYTES. Anyway, seems to be okay then.

Kevin

signature.asc
Description: PGP signature