Re: [Qemu-devel] [PATCH v2] util/hbitmap: strict hbitmap_reset

[Vladimir Sementsov-Ogievskiy]

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 <address@hidden>
>>>>>> ---
>>>>>>
>>>>>> 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 <address@hidden>
>>>>
>>>> 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