Christophe Leroy <[email protected]> writes: > Le 06/11/2025 à 16:02, David Hildenbrand (Red Hat) a écrit : >>>> Yes, we discussed that in [1]. >>>> >>>> We'll have to set ARCH_HAS_GIGANTIC_PAGE on ppc and increase >>>> MAX_FOLIO_ORDER, because apparently, there might be ppc configs that >>>> have even larger hugetlb sizes than PUDs. >>>> >>>> @Cristophe, I was under the impression that you would send a fix. Do you >>>> want me to prepare something and send it out? >>> >>> Indeed I would have liked to better understand the implications of all >>> this, but I didn't have the time. >> >> Indeed, too me longer than it should to understand and make up my mind >> as well. >> >>> >>> By the way, you would describe the fix better than me so yes if you can >>> prepare and send a fix please do. >> >> I just crafted the following. I yet have to test it more, some early >> feedback+testing would be appreciated! >> >> From 274928854644c49c92515f8675c090dba15a0db6 Mon Sep 17 00:00:00 2001 >> From: "David Hildenbrand (Red Hat)" <[email protected]> >> Date: Thu, 6 Nov 2025 11:31:45 +0100 >> Subject: [PATCH] mm: fix MAX_FOLIO_ORDER on some ppc64 configs with hugetlb >> >> In the past, CONFIG_ARCH_HAS_GIGANTIC_PAGE indicated that we support >> runtime allocation of gigantic hugetlb folios. In the meantime it evolved >> into a generic way for the architecture to state that it supports >> gigantic hugetlb folios. >> >> In commit fae7d834c43c ("mm: add __dump_folio()") we started using >> CONFIG_ARCH_HAS_GIGANTIC_PAGE to decide MAX_FOLIO_ORDER: whether we could >> have folios larger than what the buddy can handle. In the context of >> that commit, we started using MAX_FOLIO_ORDER to detect page corruptions >> when dumping tail pages of folios. Before that commit, we assumed that >> we cannot have folios larger than the highest buddy order, which was >> obviously wrong. >> >> In commit 7b4f21f5e038 ("mm/hugetlb: check for unreasonable folio sizes >> when registering hstate"), we used MAX_FOLIO_ORDER to detect >> inconsistencies, and in fact, we found some now. >> >> Powerpc allows for configs that can allocate gigantic folio during boot >> (not at runtime), that do not set CONFIG_ARCH_HAS_GIGANTIC_PAGE and can >> exceed PUD_ORDER. >> >> To fix it, let's make powerpc select CONFIG_ARCH_HAS_GIGANTIC_PAGE for >> all 64bit configs, and increase the maximum folio size to P4D_ORDER. >> >> Ideally, we'd have a better way to obtain a maximum value. But this should >> be good enough for now fix the issue and now mostly states "no real folio >> size limit". >> >> While at it, handle gigantic DAX folios more clearly: DAX can only >> end up creating gigantic folios with HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD. >> >> Add a new Kconfig option HAVE_GIGANTIC_FOLIOS to make both cases >> clearer. In particular, worry about ARCH_HAS_GIGANTIC_PAGE only with >> HUGETLB_PAGE. >> >> Note: with enabling CONFIG_ARCH_HAS_GIGANTIC_PAGE on PPC64, we will now >> also allow for runtime allocations of folios in some more powerpc configs. >> I don't think this is a problem, but if it is we could handle it through >> __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED. >> >> While __dump_page()/__dump_folio was also problematic (not handling dumping >> of tail pages of such gigantic folios correctly), it doesn't relevant >> critical enough to mark it as a fix. >> >> Fixes: 7b4f21f5e038 ("mm/hugetlb: check for unreasonable folio sizes >> when registering hstate") >> Signed-off-by: David Hildenbrand (Red Hat) <[email protected]> >> --- >> arch/powerpc/Kconfig | 1 + >> arch/powerpc/platforms/Kconfig.cputype | 1 - >> include/linux/mm.h | 4 ++-- >> include/linux/pgtable.h | 1 + >> mm/Kconfig | 7 +++++++ >> 5 files changed, 11 insertions(+), 3 deletions(-) >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index e24f4d88885ae..55c3626c86273 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -137,6 +137,7 @@ config PPC >> select ARCH_HAS_DMA_OPS if PPC64 >> select ARCH_HAS_FORTIFY_SOURCE >> select ARCH_HAS_GCOV_PROFILE_ALL >> + select ARCH_HAS_GIGANTIC_PAGE if PPC64
The patch looks good from PPC64 perspective, it also fixes the problem reported on corenet64_smp_defconfig... > > Problem is not only on PPC64, it is on PPC32 as well, for instance > corenet32_smp_defconfig has the problem as well. > However on looking deeper into it - I agree with Christophe that this problem might still exist on PPC32. I did try the patch on corenet32_smp_defconfig and I can see the WARN_ON still triggering. You can check the logs here.. https://github.com/riteshharjani/linux-ci/actions/runs/19169468405/job/54799498288 > > So I think what you want instead is: > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 7b527d18aa5ee..1f5a1e587740c 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -276,6 +276,7 @@ config PPC_E500 > select FSL_EMB_PERFMON > bool > select ARCH_SUPPORTS_HUGETLBFS if PHYS_64BIT || PPC64 > + select ARCH_HAS_GIGANTIC_PAGE if ARCH_SUPPORTS_HUGETLBFS > select PPC_SMP_MUXED_IPI > select PPC_DOORBELL > select PPC_KUEP > > > @Christophe, I don't think even the above diff will fix the warning on PPC32. The patch defines MAX_FOLIO_ORDER as P4D_ORDER... +#define MAX_FOLIO_ORDER P4D_ORDER +#define P4D_ORDER (P4D_SHIFT - PAGE_SHIFT) and for ppc32 in.. include/asm-generic/pgtable-nop4d.h #define P4D_SHIFT PGDIR_SHIFT Then in.. arch/powerpc/include/asm/nohash/32/pgtable.h #define PGDIR_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE) #define PTE_INDEX_SIZE PTE_SHIFT in... arch/powerpc/include/asm/page_32.h #define PTE_SHIFT (PAGE_SHIFT - PTE_T_LOG2) /* full page */ #define PTE_T_LOG2 (__builtin_ffs(sizeof(pte_t)) - 1) So if you see from above P4D_ORDER is coming down to PTE_INDEX_SIZE IIUC, that will cause MAX_FOLIO_ORDER to be 9 in case of e500mc machine type right? Can you please confirm if the above analysis looks correct to you? -ritesh >> select ARCH_HAS_KCOV >> select ARCH_HAS_KERNEL_FPU_SUPPORT if PPC64 && PPC_FPU >> select ARCH_HAS_MEMBARRIER_CALLBACKS >> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/ >> platforms/Kconfig.cputype >> index 7b527d18aa5ee..4c321a8ea8965 100644 >> --- a/arch/powerpc/platforms/Kconfig.cputype >> +++ b/arch/powerpc/platforms/Kconfig.cputype >> @@ -423,7 +423,6 @@ config PPC_64S_HASH_MMU >> config PPC_RADIX_MMU >> bool "Radix MMU Support" >> depends on PPC_BOOK3S_64 >> - select ARCH_HAS_GIGANTIC_PAGE > > Should remain I think. > >> default y >> help >> Enable support for the Power ISA 3.0 Radix style MMU. Currently >> this >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index d16b33bacc32b..4842edc875185 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -2074,7 +2074,7 @@ static inline unsigned long folio_nr_pages(const >> struct folio *folio) >> return folio_large_nr_pages(folio); >> } >> >> -#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) >> +#if !defined(CONFIG_HAVE_GIGANTIC_FOLIOS) >> /* >> * We don't expect any folios that exceed buddy sizes (and consequently >> * memory sections). >> @@ -2092,7 +2092,7 @@ static inline unsigned long folio_nr_pages(const >> struct folio *folio) >> * There is no real limit on the folio size. We limit them to the >> maximum we >> * currently expect (e.g., hugetlb, dax). >> */ >> -#define MAX_FOLIO_ORDER PUD_ORDER >> +#define MAX_FOLIO_ORDER P4D_ORDER >> #endif >> >> #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER) >> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >> index 32e8457ad5352..09fc3c2ba39e2 100644 >> --- a/include/linux/pgtable.h >> +++ b/include/linux/pgtable.h >> @@ -7,6 +7,7 @@ >> >> #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT) >> #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT) >> +#define P4D_ORDER (P4D_SHIFT - PAGE_SHIFT) >> >> #ifndef __ASSEMBLY__ >> #ifdef CONFIG_MMU >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 0e26f4fc8717b..ca3f146bc7053 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -908,6 +908,13 @@ config PAGE_MAPCOUNT >> config PGTABLE_HAS_HUGE_LEAVES >> def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE >> >> +# >> +# We can end up creating gigantic folio. >> +# >> +config HAVE_GIGANTIC_FOLIOS >> + def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \ >> + (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) >> + >> # TODO: Allow to be enabled without THP >> config ARCH_SUPPORTS_HUGE_PFNMAP >> def_bool n
