11.09.2019 20:59, John Snow wrote: > > > On 9/11/19 11:13 AM, Vladimir Sementsov-Ogievskiy wrote: >> 07.08.2019 19:27, John Snow wrote: >>> >>> >>> On 8/6/19 12:19 PM, Vladimir Sementsov-Ogievskiy wrote: >>>> 06.08.2019 19:09, Max Reitz wrote: >>>>> On 06.08.19 17:26, Vladimir Sementsov-Ogievskiy wrote: >>>>>> hbitmap_reset has an unobvious property: it rounds requested region up. >>>>>> It may provoke bugs, like in recently fixed write-blocking mode of >>>>>> mirror: user calls reset on unaligned region, not keeping in mind that >>>>>> there are possible unrelated dirty bytes, covered by rounded-up region >>>>>> and information of this unrelated "dirtiness" will be lost. >>>>>> >>>>>> Make hbitmap_reset strict: assert that arguments are aligned, allowing >>>>>> only one exception when @start + @count == hb->orig_size. It's needed >>>>>> to comfort users of hbitmap_next_dirty_area, which cares about >>>>>> hb->orig_size. >>>>>> >>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >>>>>> --- >>>>>> >>>>>> v2 based on Max's https://github.com/XanClic/qemu.git block >>>>>> which will be merged soon to 4.1, and this patch goes to 4.2 >>>>>> Based-on: https://github.com/XanClic/qemu.git block >>>>>> >>>>>> v1 was "[PATCH] util/hbitmap: fix unaligned reset", and as I understand >>>>>> we all agreed to just assert alignment instead of aligning down >>>>>> automatically. >>>>>> >>>>>> include/qemu/hbitmap.h | 5 +++++ >>>>>> tests/test-hbitmap.c | 2 +- >>>>>> util/hbitmap.c | 4 ++++ >>>>>> 3 files changed, 10 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h >>>>>> index 4afbe6292e..7865e819ca 100644 >>>>>> --- a/include/qemu/hbitmap.h >>>>>> +++ b/include/qemu/hbitmap.h >>>>>> @@ -132,6 +132,11 @@ void hbitmap_set(HBitmap *hb, uint64_t start, >>>>>> uint64_t count); >>>>>> * @count: Number of bits to reset. >>>>>> * >>>>>> * Reset a consecutive range of bits in an HBitmap. >>>>>> + * @start and @count must be aligned to bitmap granularity. The only >>>>>> exception >>>>>> + * is resetting the tail of the bitmap: @count may be equal to @start + >>>>>> + * hb->orig_size, >>>>> >>>>> s/@start + hb->orig_size/hb->orig_size - @start/, I think. >>>> >>>> Ha, I wanted to say start + count equal to orig_size. Yours is OK too of >>>> course. >>>> >>>>> >>>>>> in this case @count may be not aligned. @start + @count >>>>> >>>>> +are >>>>> >>>>> With those fixed: >>>>> >>>>> Reviewed-by: Max Reitz <mre...@redhat.com> >>>> >>>> Thanks! >>>> >>> >>> I'll add this to the pile for 4.2, after I fix the rebase conflicts that >>> arose from 4.1-rc4. >>> >> >> Hi! >> >> Didn't you forget, or should I resend? >> >> > > I must have dropped the patch by accident during the rebasing. As an > apology, I squashed in Max's suggestions from the list. Check that they > look OK, please? > > Thanks, applied to my bitmaps tree: > > https://github.com/jnsnow/qemu/commits/bitmaps > https://github.com/jnsnow/qemu.git >
Thanks! Still: Quote from your branch: > * Reset a consecutive range of bits in an HBitmap. > + * @start and @count must be aligned to bitmap granularity. The only > exception > + * is resetting the tail of the bitmap: @count may be equal to > hb->orig_size - > + * start, in this case @count may be not aligned. @start + @count are s/start/@start/ (corresponds to Max's comment, too) Also, I'm not sure about "are" suggested by Max. "are" is for plural, but here I meant one object: sum of @start and @count. So, you may use exactly "Sum of @start and @count is" or "(@start + @count) sum is" or just "(@start + @count) is", whichever you like more. > + * allowed to be greater than hb->orig_size, but only if @start < > hb->orig_size > + * and @start + @count = ALIGN_UP(hb->orig_size, granularity). > */ > void hbitmap_reset(HBitmap *hb, uint64_t start, uint64_t count); -- Best regards, Vladimir