On 19/02/2026 3:42 pm, Jan Beulich wrote:
> There's no need to subtract "bit" in what is passed to __scanbit(), as the
> other bits are zero anyway after the shift (in __find_next_bit()) or can
> be made so (in __find_next_zero_bit()) by flipping negation and shift. (We
> actually leverage the same facts in find_next{,_zero}_bit() as well.) This
> way in __scanbit() the TZCNT alternative can be engaged.
>
> Signed-off-by: Jan Beulich <[email protected]>Acked-by: Andrew Cooper <[email protected]> I agree that we're already doing that in find_next{,_zero}_bit() and therefore ought to be safe here. What's really confusing about all of this is that __scanbit() differs from ffs() by wanting a return value in the range [1, 64). With that in mind, I think we can do exactly the same as we do in arch_ffs(), but preloading with BITS_PER_LONG rather than -1. That in turn removes the alternative and simplifies things further. ~Andrew
