[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v2] bitmap: Update count after a me
From: |
John Snow |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v2] bitmap: Update count after a merge |
Date: |
Wed, 3 Oct 2018 16:48:37 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 10/02/2018 07:33 PM, John Snow wrote:
> From: Eric Blake <address@hidden>
>
> 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: address@hidden
> Signed-off-by: Eric Blake <address@hidden>
> Signed-off-by: John Snow <address@hidden>
> ---
>
> 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;
> }
>
>
Tests on the way, but for now...
Thanks, applied to my bitmaps tree:
https://github.com/jnsnow/qemu/commits/bitmaps
https://github.com/jnsnow/qemu.git
--js
Re: [Qemu-block] [Qemu-devel] [PATCH v2] bitmap: Update count after a merge,
John Snow <=