On Tue, Mar 17, 2026 at 11:14:11AM +0200, Leon Romanovsky wrote: > 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 <[email protected]>
Thanks, Leon. Seemingly no headwinds for the patch. Taking in in -next for testing. Thanks, Yury
