Re: New Defects reported by Coverity Scan for XenProject

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.09.2025 14:48, Alejandro Vallejo wrote:
> On Mon Sep 8, 2025 at 1:25 PM CEST, Jan Beulich wrote:
>> On 08.09.2025 13:04, Alejandro Vallejo wrote:
>>> On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
>>>> On 07.09.2025 16:37, scan-admin@xxxxxxxxxxxx wrote:
>>>>> ** CID 1665362:       Integer handling issues  (INTEGER_OVERFLOW)
>>>>> /xen/lib/find-next-bit.c: 104           in find_next_zero_bit()
>>>>>
>>>>>
>>>>> _____________________________________________________________________________________________
>>>>> *** CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>> /xen/lib/find-next-bit.c: 104             in find_next_zero_bit()
>>>>> 98        }
>>>>> 99        if (!size)
>>>>> 100               return result;
>>>>> 101       tmp = *p;
>>>>> 102     
>>>>> 103     found_first:
>>>>>>>>     CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>>>>>     Expression "0xffffffffffffffffUL << size", where "size" is known 
>>>>>>>> to be equal to 63, overflows the type of "0xffffffffffffffffUL << 
>>>>>>>> size", which is type "unsigned long".
>>>>> 104       tmp |= ~0UL << size;
>>>>> 105       if (tmp == ~0UL)        /* Are any bits zero? */
>>>>> 106               return result + size;   /* Nope. */
>>>>> 107     found_middle:
>>>>> 108       return result + ffz(tmp);
>>>>> 109     }
>>>>
>>>> I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply
>>>> 0x8000000000000000UL, isn't it? Where's the overflow there? There also
>>>> cannot be talk of a 32-bit build, or else ~0UL would have been transformed
>>>> to 0xffffffffUL.
>>>
>>> The offending line LGTM too.
>>>
>>> The only credible explanation I can think of is Coverity flagging discarded 
>>> 1s
>>> on left shifts as loss of precision.
>>>
>>> If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it 
>>> happy,
>>> but surely that error would flare up with all uses of GENMASK() too?
>>
>> And with any other non-zero values of "size" here.
> 
> Is this the only issue flagged? Or are there any others of the same kind? It
> might me easier to spot a pattern with a larger dataset.

I've seen only this one report.

Jan