qemu-block
[Top][All Lists]
Advanced

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

[Qemu-block] [PATCH for-4.1] util/hbitmap: update orig_size on truncate


From: Vladimir Sementsov-Ogievskiy
Subject: [Qemu-block] [PATCH for-4.1] util/hbitmap: update orig_size on truncate
Date: Mon, 5 Aug 2019 15:01:20 +0300

Without this, hbitmap_next_zero and hbitmap_next_dirty_area are broken
after truncate. So, orig_size is broken since it's introduction in
76d570dc495c56bb.

Fixes: 76d570dc495c56bb
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
---

Hi!

Here is one more hbitmap bug I noticed. It's my fault, I'm sorry :(
Broken in 4.0, but if we are already going to fix in 4.1 some things
around it, it's a small meaningful addition.

Users of broken API are incremental backup, sync mirror (but it may not
be broken, if truncates not allowed during mirror, are they?), bitmap
export through NBD.

 util/hbitmap.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/util/hbitmap.c b/util/hbitmap.c
index 7905212a8b..bcc0acdc6a 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -53,7 +53,9 @@
  */
 
 struct HBitmap {
-    /* Size of the bitmap, as requested in hbitmap_alloc. */
+    /*
+     * Size of the bitmap, as requested in hbitmap_alloc or in 
hbitmap_truncate.
+     */
     uint64_t orig_size;
 
     /* Number of total bits in the bottom level.  */
@@ -732,6 +734,8 @@ void hbitmap_truncate(HBitmap *hb, uint64_t size)
     uint64_t num_elements = size;
     uint64_t old;
 
+    hb->orig_size = size;
+
     /* Size comes in as logical elements, adjust for granularity. */
     size = (size + (1ULL << hb->granularity) - 1) >> hb->granularity;
     assert(size <= ((uint64_t)1 << HBITMAP_LOG_MAX_SIZE));
-- 
2.18.0




reply via email to

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