[akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0

[Matthew Wilcox]

On Fri, Nov 14, 2025 at 11:29:56AM -0700, Nathan Chancellor wrote:
> > >> mm/util.c:1263:16: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
> >     1263 |         if (ps->idx < MAX_FOLIO_NR_PAGES) {
> >          |                       ^~~~~~~~~~~~~~~~~~
> >    include/linux/mm.h:2104:36: note: expanded from macro 'MAX_FOLIO_NR_PAGES'
> >     2104 | #define MAX_FOLIO_NR_PAGES      (1UL << MAX_FOLIO_ORDER)
> >          |                                         ^~~~~~~~~~~~~~~
> >    include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
> >     2095 | #define MAX_FOLIO_ORDER         get_order(SZ_16G)
> >          |                                 ~~~~~~~~~ ^~~~~~
> >    include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
> >       56 | #define SZ_16G                          _AC(0x400000000, ULL)
> >          |                                         ^~~~~~~~~~~~~~~~~~~~~

Clearly this is a 32-bit build, since otherwise a conversion from
"unsigned long long" to "unsigned long" is a NOP.  But 32-bit cannot
support 16GB folios!

I say this is a bug in powerpc32's config.

#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE)
#define MAX_FOLIO_ORDER         MAX_PAGE_ORDER
...
#else
#define MAX_FOLIO_ORDER         PUD_ORDER

(PUD_ORDER is 16GB, so I think this will be what's being picked up)

but the only place the mentions ARCH_HAS_GIGANTIC_PAGE is pretty
clearly dependent on 64bit ...

config PPC_RADIX_MMU
        bool "Radix MMU Support"
        depends on PPC_BOOK3S_64
        select ARCH_HAS_GIGANTIC_PAGE

so I'm a bit stuck about how this comes to be.  Adding the PPC people
for thoughts.