Am 15.11.2018 um 17:28 hat Eric Blake geschrieben:
> On 11/15/18 9:45 AM, Kevin Wolf wrote:
> > Am 15.11.2018 um 03:03 hat Eric Blake geschrieben:
> > > This change has no semantic impact: all drivers either leave the
> > > value at 0 (no inherent 32-bit limit is still translated into
> > > fragmentation below 2G; see the previous patch for that audit), or
> > > set it to a value less than 2G. However, switching to a larger
> > > type and enforcing the 2G cap at the block layer makes it easier
> > > to audit specific drivers for their robustness to larger sizing,
> > > by letting them specify a value larger than INT_MAX if they have
> > > been audited to be 64-bit clean.
> > >
>
> > > +++ b/block/io.c
> > > @@ -159,6 +159,13 @@ void bdrv_refresh_limits(BlockDriverState *bs, Error
> > > **errp)
> > > if (drv->bdrv_refresh_limits) {
> > > drv->bdrv_refresh_limits(bs, errp);
> > > }
> > > +
> > > + /* Clamp max_transfer to 2G */
> > > + if (bs->bl.max_transfer > UINT32_MAX) {
> >
> > UINT32_MAX is 4G, not 2G.
> >
> > Would it make more sense to make BDRV_REQUEST_MAX_BYTES the maximum
> > anyway?
>
> D'oh. Yes, that's what I intended, possibly by spelling it INT_MAX (the
> fact that the 'if' goes away in patch 13 is not an excuse for sloppy coding
> in the meantime).
INT_MAX is not a different spelling of BDRV_REQUEST_MAX_BYTES. The
latter is slightly lower (0x7ffffe00).
Kevin
