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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 10.11.25 11:33, Christophe Leroy wrote:
> 
> 
> Le 10/11/2025 à 11:10, David Hildenbrand (Red Hat) a écrit :
>> [fighting with mail transitioning, for some reason I did not receive
>> the mails from Christophe, so replying here]
>>
>>>>> 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.
>>
>> Ah, I missed that. I thought it would be a ppc64 thing. :(
>>
>>>
>>> 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://eur01.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fgithub.com%2Friteshharjani%2Flinux-
>>> ci%2Factions%2Fruns%2F19169468405%2Fjob%2F54799498288&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cf2e19b221ba740b2034e08de204158de%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638983662203106300%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UKQnlJWDKPfNCiYL8W7d2%2FTAhMhGbmxx8IDvy8jTbNQ%3D&reserved=0
>>>
>>>
>>>>
>>>> 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?
>>
>> Cristophe wrote
>>
>> "
>> Ah you are right, that's not enough. I was thinking that PGDIR_ORDER was
>> the highest possible value ever but in fact not. PGDIR_SIZE is 4Mbytes
>> so any page larger than that still triggers the warning. Here are the
>> warnings I get on QEMU with corenet32_smp_defconfig
>> "
>>
>> And then we get
>>
>> HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
>> HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
>> HugeTLB: registered 64.0 MiB page size, pre-allocated 1 pages
>> HugeTLB: 0 KiB vmemmap can be freed for a 64.0 MiB page
>> HugeTLB: registered 256 MiB page size, pre-allocated 1 pages
>> HugeTLB: 0 KiB vmemmap can be freed for a 256 MiB page
>> HugeTLB: registered 4.00 MiB page size, pre-allocated 0 pages
>> HugeTLB: 0 KiB vmemmap can be freed for a 4.00 MiB page
>> HugeTLB: registered 16.0 MiB page size, pre-allocated 0 pages
>> HugeTLB: 0 KiB vmemmap can be freed for a 16.0 MiB page
>>
>>
>> How could any of these larger sizes possibly ever get mapped into a page
>> table on 32bit? I'm probably missing something important :)
>>
> 
> Using contiguous entries in a table to describe larger pages.

Thanks, that makes sense.

Alright, let me think whether we should just have a generic "unlimited" 
thing here (e.g., max_order = 31).

-- 
Cheers

David