qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v2] qcow2-bitmap: Fix uint64_t left-shift overflow


From: Max Reitz
Subject: Re: [PATCH v2] qcow2-bitmap: Fix uint64_t left-shift overflow
Date: Tue, 29 Oct 2019 12:14:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

On 28.10.19 07:33, Tuguoyi wrote:
> In check_constraints_on_bitmap(), the sanity check on the
> granularity will cause uint64_t integer left-shift overflow
> when cluster_size is 2M and the granularity is BIGGER than
> 32K. As a result, for a qcow2 disk with cluster_size set to
> 2M, we could not even create a dirty bitmap with default
> granularity. This patch fix the issue by dividing @len by
> granularity instead.
> 
> Signed-off-by: Guoyi Tu <address@hidden>
> ---
>  block/qcow2-bitmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index 98294a7..71ac822 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -172,8 +172,8 @@ static int check_constraints_on_bitmap(BlockDriverState 
> *bs,
>      }
>  
>      if ((len > (uint64_t)BME_MAX_PHYS_SIZE << granularity_bits) ||
> -        (len > (uint64_t)BME_MAX_TABLE_SIZE * s->cluster_size <<
> -               granularity_bits))
> +        (DIV_ROUND_UP(len, granularity) > (uint64_t)BME_MAX_TABLE_SIZE *
> +                s->cluster_size))

This didn’t change because of this patch, but doesn’t this comparison
need a conversion of bits to bytes somewhere?

len / granularity gives us the number of bits needed for the bitmap.

BME_MAX_TABLE_SIZE is, as far as I can see, a number of bitmap clusters,
so multiplying it by the cluster size gives the number of bytes in the
bitmap.  But the number of bits is eight times higher.

Another topic: Isn’t BME_MAX_TABLE_SIZE too big?  As it is, bitmap
tables can have a size of 1 GB, and that’s the table alone.  Depending
on the cluster size, the bitmap would take up at least 64 GB and cover
at least 32 TB (at a granularity of 512 bytes).

Max

>      {
>          error_setg(errp, "Too much space will be occupied by the bitmap. "
>                     "Use larger granularity");
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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