From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g7UAY-00069Y-EM for qemu-devel@nongnu.org; Tue, 02 Oct 2018 19:33:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g7UAX-0005dY-Lf for qemu-devel@nongnu.org; Tue, 02 Oct 2018 19:33:34 -0400 From: John Snow Date: Tue, 2 Oct 2018 19:33:14 -0400 Message-Id: <20181002233314.30159-1-jsnow@redhat.com> Subject: [Qemu-devel] [PATCH v2] bitmap: Update count after a merge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-stable@nongnu.org Cc: qemu-block@nongnu.org, Fam Zheng , qemu-devel@nongnu.org, eblake@redhat.com, vsementsov@virtuozzo.com, John Snow From: Eric Blake We need an accurate count of the number of bits set in a bitmap after a merge. In particular, since the merge operation short-circuits a merge from an empty source, if you have bitmaps A, B, and C where B started empty, then merge C into B, and B into A, an inaccurate count meant that A did not get the contents of C. In the worst case, we may falsely regard the bitmap as empty when it has had new writes merged into it. Fixes: be58721db CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake Signed-off-by: John Snow --- v2: based off of Eric's cover letter, now rebased properly on top of the jsnow/bitmaps staging branch to use the correct bitmap target (result). util/hbitmap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/util/hbitmap.c b/util/hbitmap.c index d5aca5159f..8d402c59d9 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 */ + result->count = hb_count_between(result, 0, result->size - 1); + return true; } -- 2.14.4