summaryrefslogtreecommitdiffstats
path: root/util/hbitmap.c
diff options
context:
space:
mode:
authorEric Blake2018-10-29 21:23:17 +0100
committerJohn Snow2018-10-29 21:23:17 +0100
commitd1dde7149e376d72b422a529ec4bf3ed47f3ba30 (patch)
treecb9309127c2851e6e13394a4253fcb235d46873b /util/hbitmap.c
parentnbd: forbid use of frozen bitmaps (diff)
downloadqemu-d1dde7149e376d72b422a529ec4bf3ed47f3ba30.tar.gz
qemu-d1dde7149e376d72b422a529ec4bf3ed47f3ba30.tar.xz
qemu-d1dde7149e376d72b422a529ec4bf3ed47f3ba30.zip
bitmap: Update count after a merge
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 <eblake@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20181002233314.30159-1-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'util/hbitmap.c')
-rw-r--r--util/hbitmap.c3
1 files changed, 3 insertions, 0 deletions
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;
}