|
From: | Eric Blake |
Subject: | Re: [Qemu-block] [PATCH] util/hbitmaps: recalculate count on merge |
Date: | Thu, 27 Sep 2018 09:09:12 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
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".
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |