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. > > Jan
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. Cheers, Alejandro
