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.

Fixes: be58721db
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
---

Probably worth some testsuite coverage, but for a late-night one-liner,
this is as much as I can do today.

 util/hbitmap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/util/hbitmap.c b/util/hbitmap.c
index bcd304041aa..52e12da4b48 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -753,3 +753,4 @@ bool hbitmap_merge(HBitmap *a, const HBitmap *b)
             a->levels[i][j] |= b->levels[i][j];
         }
     }
+    a->count = hb_count_between(a, 0, a->size - 1);

     return true;
 }
-- 
2.17.1

27.09.2018 06:11, Eric Blake wrote:
> 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.
>
> Fixes: be58721db
> CC: qemu-stable@nongnu.org
> Signed-off-by: Eric Blake <eblake@redhat.com>


Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

> ---
>
> Probably worth some testsuite coverage, but for a late-night one-liner,
> this is as much as I can do today.
>
>   util/hbitmap.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index bcd304041aa..52e12da4b48 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -753,3 +753,4 @@ bool hbitmap_merge(HBitmap *a, const HBitmap *b)
>               a->levels[i][j] |= b->levels[i][j];
>           }
>       }
> +    a->count = hb_count_between(a, 0, a->size - 1);
>
>       return true;
>   }


-- 
Best regards,
Vladimir

On 09/26/2018 11:11 PM, Eric Blake wrote:
> 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.
> 
> Fixes: be58721db
> CC: qemu-stable@nongnu.org
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> 
> Probably worth some testsuite coverage, but for a late-night one-liner,
> this is as much as I can do today.
> 
>  util/hbitmap.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index bcd304041aa..52e12da4b48 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -753,3 +753,4 @@ bool hbitmap_merge(HBitmap *a, const HBitmap *b)
>              a->levels[i][j] |= b->levels[i][j];
>          }
>      }
> +    a->count = hb_count_between(a, 0, a->size - 1);
> 
>      return true;
>  }
> 

OK, tests coming up. Thanks for the CC to stable.

--js

On 9/27/18 12:23 PM, John Snow wrote:
> 
> 
> On 09/26/2018 11:11 PM, Eric Blake wrote:
>> 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.
>>

> 
> OK, tests coming up. Thanks for the CC to stable.

Did we ever add tests for this yet?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On 11/09/2018 12:57 PM, Eric Blake wrote:
> On 9/27/18 12:23 PM, John Snow wrote:
>>
>>
>> On 09/26/2018 11:11 PM, Eric Blake wrote:
>>> 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.
>>>
> 
>>
>> OK, tests coming up. Thanks for the CC to stable.
> 
> Did we ever add tests for this yet?
> 

Running behind. Not yet. On my list.