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-ad...@coverity.com 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
