On 14.11.25 20:18, Nathan Chancellor wrote:
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/[email protected]/
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?
God how I HATE that hugetlb crap at this point. So much wasted time.
Likely, for 32bit builds we should cap it at 1 GiB, which I think is the
32bit maximum hugetlb folios size on ppc actually is.
--
Cheers
David
