Re: [PATCH] lib: count_zeros: fix 32/64-bit inconsistency in count_trailing_zeros()

[Leon Romanovsky <leon@kernel.org>]

On Fri, Mar 13, 2026 at 02:14:49PM -0400, Yury Norov wrote:
> On Fri, Mar 13, 2026 at 02:18:55PM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 12, 2026 at 07:08:16PM -0400, Yury Norov wrote:
> > > Based on 'sizeof(x) == 4' condition, in 32-bit case the function is wired
> > > to ffs(), while in 64-bit case to __ffs(). The difference is substantial:
> > > ffs(x) == __ffs(x) + 1. Also, ffs(0) == 0, while __ffs(0) is undefined.
> > > 
> > > The 32-bit behaviour is inconsistent with the function description, so it
> > > needs to get fixed.
> > > 
> > > There are 9 individual users for the function in 6 different subsystems.
> > > Some arches and drivers are 64-bit only:
> > >  - arch/loongarch/kvm/intc/eiointc.c;
> > >  - drivers/hv/mshv_vtl_main.c;
> > >  - kernel/liveupdate/kexec_handover.c;
> > > 
> > > The others are:
> > >  - ib_umem_find_best_pgsz(): as per comment, __ffs() should be correct;
> > 
> > So long as 32 bit works the same as 64 bit it is correct for ib
> 
> This is what the patch does, except that it doesn't account for the
> word length. In you case, 'mask' is dma_addr_t, which is u32 or u64
> depending ARCH_DMA_ADDR_T_64BIT.
> 
> This config is:
> 
>         config ARCH_DMA_ADDR_T_64BIT
>                 def_bool 64BIT || PHYS_ADDR_T_64BIT
> 
> And PHYS_ADDR_T_64BIT is simply def_bool 64BIT. So, at least now
> dma_addr_t simply follows unsigned long, and thus, the patch is
> correct. But IDK what's the history behind this configurations.
> 
> Anyways, the patch aligns 32-bit count_trailing_zeros() with the
> 64-bit one. If you OK with that, as you said, can you please send
> an explicit ack?

I can do that, 32 bits architectures are rarely used in the IB world.

Thanks,
Acked-by: Leon Romanovsky <leon@kernel.org>