find_next{,_zero}_bit() inconsistencies

find_next{,_zero}_bit() inconsistencies

[Jan Beulich]

Hello,

in the context of
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
I once again came across the different behavior our various
implementations of the $subject functions, in particular their varying
handling of the offset argument being greater / greater-or-equal
the size argument. Shouldn't we settle on a single, uniform model,
which might be
1) offset >= size is valid, returns size,
2) offset == size is valid, returns size, offset > size is invalid,
3) offset >= size is invalid.

Thanks for opinions, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: find_next{,_zero}_bit() inconsistencies

[Andrew Cooper]

On 29/08/2016 12:59, Jan Beulich wrote:
> Hello,
>
> in the context of
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
> I once again came across the different behavior our various
> implementations of the $subject functions, in particular their varying
> handling of the offset argument being greater / greater-or-equal
> the size argument. Shouldn't we settle on a single, uniform model,
> which might be
> 1) offset >= size is valid, returns size,
> 2) offset == size is valid, returns size, offset > size is invalid,
> 3) offset >= size is invalid.
>
> Thanks for opinions, Jan
>

A number of existing situations use size as an end sentinel, so option 3
will probably break things.

What did you have in mind for invalid?  Option 2 is probably the better
angle, especially for catching errors, but it is might show up some
existing latently-buggy code which would also need fixing.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: find_next{,_zero}_bit() inconsistencies

[Jan Beulich]

>>> On 29.08.16 at 14:03, <andrew.cooper3@citrix.com> wrote:
> On 29/08/2016 12:59, Jan Beulich wrote:
>> in the context of
>> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html 
>> I once again came across the different behavior our various
>> implementations of the $subject functions, in particular their varying
>> handling of the offset argument being greater / greater-or-equal
>> the size argument. Shouldn't we settle on a single, uniform model,
>> which might be
>> 1) offset >= size is valid, returns size,
>> 2) offset == size is valid, returns size, offset > size is invalid,
>> 3) offset >= size is invalid.
>>
>> Thanks for opinions, Jan
> 
> A number of existing situations use size as an end sentinel, so option 3
> will probably break things.

But otoh the ARM32 variant looks broken even for offset == size
(when both are a multiple of 8 the first byte after the array would
get accessed).

> What did you have in mind for invalid?

ASSERT()

>  Option 2 is probably the better
> angle, especially for catching errors, but it is might show up some
> existing latently-buggy code which would also need fixing.

I agree - that's why I'm asking for opinions first.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: find_next{,_zero}_bit() inconsistencies

[David Vrabel]

On 29/08/16 12:59, Jan Beulich wrote:
> Hello,
> 
> in the context of
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
> I once again came across the different behavior our various
> implementations of the $subject functions, in particular their varying
> handling of the offset argument being greater / greater-or-equal
> the size argument. Shouldn't we settle on a single, uniform model,
> which might be
> 1) offset >= size is valid, returns size,
> 2) offset == size is valid, returns size, offset > size is invalid,
> 3) offset >= size is invalid.

What does the linux implementation do?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: find_next{,_zero}_bit() inconsistencies

[Jan Beulich]

>>> On 30.08.16 at 11:26, <david.vrabel@citrix.com> wrote:
> On 29/08/16 12:59, Jan Beulich wrote:
>> Hello,
>> 
>> in the context of
>> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html 
>> I once again came across the different behavior our various
>> implementations of the $subject functions, in particular their varying
>> handling of the offset argument being greater / greater-or-equal
>> the size argument. Shouldn't we settle on a single, uniform model,
>> which might be
>> 1) offset >= size is valid, returns size,
>> 2) offset == size is valid, returns size, offset > size is invalid,
>> 3) offset >= size is invalid.
> 
> What does the linux implementation do?

Their generic implementation follows 1). I didn't go and check arch
overrides.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: find_next{,_zero}_bit() inconsistencies

[Julien Grall]

Hi Jan,

On 30/08/16 11:08, Jan Beulich wrote:
>>>> On 30.08.16 at 11:26, <david.vrabel@citrix.com> wrote:
>> On 29/08/16 12:59, Jan Beulich wrote:
>>> Hello,
>>>
>>> in the context of
>>> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
>>> I once again came across the different behavior our various
>>> implementations of the $subject functions, in particular their varying
>>> handling of the offset argument being greater / greater-or-equal
>>> the size argument. Shouldn't we settle on a single, uniform model,
>>> which might be
>>> 1) offset >= size is valid, returns size,
>>> 2) offset == size is valid, returns size, offset > size is invalid,
>>> 3) offset >= size is invalid.
>>
>> What does the linux implementation do?
>
> Their generic implementation follows 1). I didn't go and check arch
> overrides.

The ARM64 implementation of find_next_*_bit is a verbatim copy for the 
generic Linux implementation.

ARM32 has its own implementation of find_next_*_bit and follows 1).

So I would lean towards option 1.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel