[Qemu-devel] [PULL 0/1] hbitmap fix for 2.8

[Qemu-devel] [PULL 0/1] hbitmap fix for 2.8

[Fam Zheng]

The following changes since commit 00227fefd2059464cd2f59aed29944874c630e2f:

  Update version for v2.8.0-rc1 release (2016-11-22 22:29:08 +0000)

are available in the git repository at:

  git://github.com/famz/qemu.git tags/for-upstream

for you to fetch changes up to 6725f887acc023fc8850d62e1aaef083fdb4f3d4:

  hbitmap: Fix shifts of constants by granularity (2016-11-29 17:46:36 +0800)

----------------------------------------------------------------

----------------------------------------------------------------

Max Reitz (1):
  hbitmap: Fix shifts of constants by granularity

 util/hbitmap.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
2.9.3

[Qemu-devel] [PULL 1/1] hbitmap: Fix shifts of constants by granularity

[Fam Zheng]

From: Max Reitz <mreitz@redhat.com>

An hbitmap's granularity may be anything from 0 to 63, so when shifting
constants by its value, they should not be plain ints.

Even having changed the types, hbitmap_serialization_granularity() still
tries to shift 64 to the right by the granularity. This operation is
undefined if the granularity is greater than 57. Adding an assertion is
fine for now, because serializing is done only in tests so far, but this
means that only bitmaps with a granularity below 58 can be serialized
and we should thus add a hbitmap_is_serializable() function later.

One of the two places touched in this patch uses
QEMU_ALIGN_UP(x, 1 << y). We can use ROUND_UP() there, since the second
parameter is obviously a power of two.

Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20161115224732.1334-1-mreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
---
 util/hbitmap.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/util/hbitmap.c b/util/hbitmap.c
index 5d1a21c..9f691b7 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -399,9 +399,13 @@ bool hbitmap_get(const HBitmap *hb, uint64_t item)
 
 uint64_t hbitmap_serialization_granularity(const HBitmap *hb)
 {
+    /* Must hold true so that the shift below is defined
+     * (ld(64) == 6, i.e. 1 << 6 == 64) */
+    assert(hb->granularity < 64 - 6);
+
     /* Require at least 64 bit granularity to be safe on both 64 bit and 32 bit
      * hosts. */
-    return 64 << hb->granularity;
+    return UINT64_C(64) << hb->granularity;
 }
 
 /* Start should be aligned to serialization granularity, chunk size should be
@@ -594,7 +598,7 @@ void hbitmap_truncate(HBitmap *hb, uint64_t size)
     if (shrink) {
         /* Don't clear partial granularity groups;
          * start at the first full one. */
-        uint64_t start = QEMU_ALIGN_UP(num_elements, 1 << hb->granularity);
+        uint64_t start = ROUND_UP(num_elements, UINT64_C(1) << hb->granularity);
         uint64_t fix_count = (hb->size << hb->granularity) - start;
 
         assert(fix_count);
-- 
2.9.3

Re: [Qemu-devel] [PULL 0/1] hbitmap fix for 2.8

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On Tue, Nov 29, 2016 at 06:34:37PM +0800, Fam Zheng wrote:
> The following changes since commit 00227fefd2059464cd2f59aed29944874c630e2f:
> 
>   Update version for v2.8.0-rc1 release (2016-11-22 22:29:08 +0000)
> 
> are available in the git repository at:
> 
>   git://github.com/famz/qemu.git tags/for-upstream
> 
> for you to fetch changes up to 6725f887acc023fc8850d62e1aaef083fdb4f3d4:
> 
>   hbitmap: Fix shifts of constants by granularity (2016-11-29 17:46:36 +0800)
> 
> ----------------------------------------------------------------
> 
> ----------------------------------------------------------------
> 
> Max Reitz (1):
>   hbitmap: Fix shifts of constants by granularity
> 
>  util/hbitmap.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> -- 
> 2.9.3
> 

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]