John Snow <js...@redhat.com> writes:
> On 08/07/2017 10:45 AM, Markus Armbruster wrote:
>> Block dirty bitmaps represent granularity in bytes as uint32_t. It
>> must be a power of two and a multiple of BDRV_SECTOR_SIZE.
>>
>> The trouble with uint32_t is computations like this one in
>> mirror_do_read():
>>
>> uint64_t max_bytes;
>>
>> max_bytes = s->granularity * s->max_iov;
>>
>> The operands of * are uint32_t and int, so the product is computed in
>> uint32_t (assuming 32 bit int), then zero-extended to uint64_t.
>>
>> Since granularity is generally combined with 64 bit file offsets, it's
>> best to make it 64 bits, too. Less opportunity to screw up.
>>
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>
> [bweeooop]
>
>> --- a/block/dirty-bitmap.c
>> +++ b/block/dirty-bitmap.c
>
> [buuuuweeeep]
>
>> @@ -506,16 +506,11 @@ uint32_t
>> bdrv_get_default_bitmap_granularity(BlockDriverState *bs)
>> return granularity;
>> }
>>
>> -uint32_t bdrv_dirty_bitmap_granularity(const BdrvDirtyBitmap *bitmap)
>> +uint64_t bdrv_dirty_bitmap_granularity(const BdrvDirtyBitmap *bitmap)
>> {
>> return BDRV_SECTOR_SIZE << hbitmap_granularity(bitmap->bitmap);
>> }
>>
>> -uint32_t bdrv_dirty_bitmap_meta_granularity(BdrvDirtyBitmap *bitmap)
>> -{
>> - return BDRV_SECTOR_SIZE << hbitmap_granularity(bitmap->meta);
>> -}
>
> Why? Unused? Not cool enough to mention?
I didn't feel like fixing an unused function, so I dropped it. Can
mention this in the commit message.
