[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

[Nathan Chancellor]

On Fri, Nov 14, 2025 at 06:54:47PM +0000, Matthew Wilcox wrote:
> 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.

Note that the original report is against mm-unstable and flags

  https://git.kernel.org/akpm/mm/c/c3f81a41ba6f93693d208edde08ce2b0da21c645
  https://lore.kernel.org/20251112145632.508687-1-david@kernel.org/

in mm-hotfixes-unstable as the problematic change. This configuration ends up
with

  $ rg -N 'HAVE_GIGANTIC|HUGETLB|PPC_8xx' .config
  # CONFIG_CGROUP_HUGETLB is not set
  CONFIG_PPC_8xx=y
  CONFIG_HAVE_GIGANTIC_FOLIOS=y
  CONFIG_ARCH_SUPPORTS_HUGETLBFS=y
  CONFIG_HUGETLBFS=y
  CONFIG_HUGETLB_PAGE=y

  config PPC_8xx
      bool "Freescale 8xx"
      select ARCH_SUPPORTS_HUGETLBFS
      select FSL_SOC
      select PPC_KUEP
      select HAVE_ARCH_VMAP_STACK
      select HUGETLBFS

which may indicate a bug in either selecting ARCH_HAS_GIGANTIC_PAGE in
this case or the logic of HAVE_GIGANTIC_FOLIOS in that change?

Cheers,
Nathan