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

[David Hildenbrand (Red Hat)]

[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://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?

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 :)

-- 
Cheers

David