Re: [PATCH next 11/14] bit: Strengthen compile-time tests in GENMASK() and BIT()

[David Laight <david.laight.linux@gmail.com>]

On Thu, 22 Jan 2026 10:25:54 +0000
David Laight <david.laight.linux@gmail.com> wrote:

> On Thu, 22 Jan 2026 09:11:53 +0800
> kernel test robot <lkp@intel.com> wrote:
> 
> > Hi,
> > 
> > kernel test robot noticed the following build errors:
> > 
> > [auto build test ERROR on next-20260120]
> > 
> > url:    https://github.com/intel-lab-lkp/linux/commits/david-laight-linux-gmail-com/overflow-Reduce-expansion-of-__type_max/20260122-013456
> > base:   next-20260120
> > patch link:    https://lore.kernel.org/r/20260121145731.3623-12-david.laight.linux%40gmail.com
> > patch subject: [PATCH next 11/14] bit: Strengthen compile-time tests in GENMASK() and BIT()
> > config: s390-randconfig-001-20260122 (https://download.01.org/0day-ci/archive/20260122/202601220829.MgTMeqqN-lkp@intel.com/config)
> > compiler: s390-linux-gcc (GCC) 8.5.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601220829.MgTMeqqN-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202601220829.MgTMeqqN-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    In file included from arch/s390/include/asm/bug.h:60,
> >                     from include/linux/bug.h:5,
> >                     from include/linux/mmdebug.h:5,
> >                     from arch/s390/include/asm/cmpxchg.h:11,
> >                     from arch/s390/include/asm/atomic.h:16,
> >                     from include/linux/atomic.h:7,
> >                     from include/asm-generic/bitops/atomic.h:5,
> >                     from arch/s390/include/asm/bitops.h:75,
> >                     from include/linux/bitops.h:67,
> >                     from include/linux/kernel.h:23,
> >                     from net/core/page_pool.c:10:
> >    In function 'netmem_clear_pp_magic',
> >        inlined from 'page_pool_clear_pp_info' at net/core/page_pool.c:721:2:  
> > >> include/linux/bits.h:35:4: error: call to 'GENMASK_INPUT_CHECK_FAIL' declared with attribute error: Invalid bit numbers    
> ...
> >    include/linux/mm.h:4641:27: note: in expansion of macro 'GENMASK'
> >     #define PP_DMA_INDEX_MASK GENMASK(PP_DMA_INDEX_BITS + PP_DMA_INDEX_SHIFT - 1, \  
> 
> This might be a real bug.
> 
> The bit of mm.h is:
> 
> #define PP_DMA_INDEX_SHIFT (1 + __fls(PP_SIGNATURE - POISON_POINTER_DELTA))
> #if POISON_POINTER_DELTA > 0
> /* PP_SIGNATURE includes POISON_POINTER_DELTA, so limit the size of the DMA
>  * index to not overlap with that if set
>  */
> #define PP_DMA_INDEX_BITS MIN(32, __ffs(POISON_POINTER_DELTA) - PP_DMA_INDEX_SHIFT)
> #else
> /* Use the lowest bit of PAGE_OFFSET if there's at least 8 bits available; see above */
> #define PP_DMA_INDEX_MIN_OFFSET (1 << (PP_DMA_INDEX_SHIFT + 8))
> #define PP_DMA_INDEX_BITS ((__builtin_constant_p(PAGE_OFFSET) && \
> 			    PAGE_OFFSET >= PP_DMA_INDEX_MIN_OFFSET && \
> 			    !(PAGE_OFFSET & (PP_DMA_INDEX_MIN_OFFSET - 1))) ? \
> 			      MIN(32, __ffs(PAGE_OFFSET) - PP_DMA_INDEX_SHIFT) : 0)
> 
> #endif
> 
> #define PP_DMA_INDEX_MASK GENMASK(PP_DMA_INDEX_BITS + PP_DMA_INDEX_SHIFT - 1, \
> 				  PP_DMA_INDEX_SHIFT)

I've managed to do an s390 cross build.
It is all quite obvious really.
For s390 PAGE_OFFSET is usually zero (I think kernel and user mappings are separate?).
This make PP_DMA_INDEX_BITS 0.
PP_SIGNATURE is 64 - so PP_DMA_INDEX_SHIFT is 7.
So it is doing GENMASK(6, 7) and, I think, expecting to get zero.
But that is taken a mistyped GENMASK(7, 6) and treated as an error.

If I rewrite __fls() and __ffs() to return 'integer constant expressions'
when the input is one I think it would always have failed.

A comment a few lines higher suggests that the code expects the mask to
be zero in this case - and handles it properly.

	David

> 
> I've no idea what the values are, but the 'hi' bit number must exceed that
> of 'long'.
> The __ffs() probably stop it being an 'integer constant expression'
> making it just a 'compile time constant' - which I added a test for.
> 
> 	David
> 
>