Re: powerpc/e500: WARNING: at mm/hugetlb.c:4755 hugetlb_add_hstate

[Ritesh Harjani (IBM) <ritesh.list@gmail.com>]

Christophe Leroy <christophe.leroy@csgroup.eu> 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)" <david@kernel.org>
>> 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) <david@kernel.org>
>> ---
>>   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