On Fri, Nov 14, 2025 at 11:29:56AM -0700, Nathan Chancellor wrote:
quoted
quoted
quoted
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.