qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] util/hbitmaps: recalculate count on merge


From: John Snow
Subject: Re: [Qemu-devel] [PATCH] util/hbitmaps: recalculate count on merge
Date: Thu, 27 Sep 2018 13:24:39 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1


On 09/27/2018 10:09 AM, Eric Blake wrote:
> On 9/27/18 2:31 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 27.09.2018 00:28, John Snow wrote:
>>> We have been neglecting to do so, which results in wrong counts
>>> after merge. In the worst case, we may think the bitmap is empty
>>> when it has had new writes merged into it.
>>>
>>> Reported-by: Eric Blake <address@hidden>
>>> Signed-off-by: John Snow <address@hidden>
>>> ---
>>>   util/hbitmap.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/util/hbitmap.c b/util/hbitmap.c
>>> index d5aca5159f..28e9c523ab 100644
>>> --- a/util/hbitmap.c
>>> +++ b/util/hbitmap.c
>>> @@ -759,6 +759,9 @@ bool hbitmap_merge(const HBitmap *a, const
>>> HBitmap *b, HBitmap *result)
>>>           }
>>>       }
>>> +    /* Recompute the dirty count */
>>> +    a->count = hb_count_between(a, 0, a->size - 1);
>>
>> hmm, just looking at function header: shouldn't we update
>> result->count instead? This code shouldn't compile (thanks to my const*)
> 
> Hmm. It looks like John and I posted essentially the same patch, but
> that John's version is based against his out-of-tree patch queue, which
> includes Vladimir's "dirty-bitmap: make it possible to restore bitmap
> after merge".
> 

Oh, I see, we each posted one. Whoops!

Yes, mine is based off of the transactionable merge series.

--js



reply via email to

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