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

[Christophe Leroy]

Hi David,

Le 29/10/2025 à 09:25, David Hildenbrand a écrit :
> On 29.10.25 06:49, Sourabh Jain wrote:
>> Kernel is printing below warning while booting:
>>
>>
>> WARNING: CPU: 0 PID: 1 at mm/hugetlb.c:4753 hugetlb_add_hstate+0xc0/0x180
>> Modules linked in:
>> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
>> 6.18.0-rc1-01400-ga297f72c4951 #6 NONE
>> Hardware name: QEMU ppce500 e5500 0x80240020 QEMU e500
>> NIP:  c000000001370800 LR: c000000001357740 CTR: 0000000000000005
>> REGS: c000000080183890 TRAP: 0700   Not tainted
>> (6.18.0-rc1-01400-ga297f72c4951)
>> MSR:  0000000080029002 <CE,EE,ME>  CR: 48000242  XER: 20000000
>> IRQMASK: 0
>> GPR00: c000000001357740 c000000080183b30 c000000001352000 
>> 000000000000000e
>> GPR04: c0000000011d1c4f 0000000000000002 000000000000001a 
>> 0000000000000000
>> GPR08: 0000000000000000 0000000000000002 0000000000000001 
>> 0000000000000005
>> GPR12: c0000000013576a4 c0000000015ad000 c00000000000210c 
>> 0000000000000000
>> GPR16: 0000000000000000 0000000000000000 0000000000000000 
>> 0000000000000000
>> GPR20: 0000000000000000 0000000000000000 0000000000000000 
>> 0000000000000000
>> GPR24: 0000000000000000 c0000000015876e8 0000000000000002 
>> c000000001587500
>> GPR28: c000000001587578 000000000000000e 0000000004000000 
>> 0000000000000170
>> NIP [c000000001370800] hugetlb_add_hstate+0xc0/0x180
>> LR [c000000001357740] hugetlbpage_init+0x9c/0xf0
>> Call Trace:
>> hugetlb_add_hstate+0x148/0x180 (unreliable)
>> hugetlbpage_init+0x9c/0xf0
>> do_one_initcall+0x84/0x308
>> kernel_init_freeable+0x2e4/0x380
>> kernel_init+0x30/0x15c
>> ret_from_kernel_user_thread+0x14/0x1c
>>
>> Kernel commit causing these warning:
>> commit 7b4f21f5e0386dfe02c68c009294d8f26e3c1bad (HEAD)
>> Author: David Hildenbrand <david at redhat.com>
>> Date:   Mon Sep 1 17:03:29 2025 +0200
>>
>>       mm/hugetlb: check for unreasonable folio sizes when registering 
>> hstate
>>
>>       Let's check that no hstate that corresponds to an unreasonable
>> folio size
>>       is registered by an architecture.  If we were to succeed
>> registering, we
>>       could later try allocating an unsupported gigantic folio size.
>>
>> ...
>>
>>           BUG_ON(order < order_base_2(__NR_USED_SUBPAGE));
>> +       WARN_ON(order > MAX_FOLIO_ORDER);
>>           h = &hstates[hugetlb_max_hstate++];
>>
>> snip...
>>
>>
>> Command to create kernel config:
>> make ARCH=powerpc corenet64_smp_defconfig
>>
>> Qemu command:
>> qemu-system-ppc64 -nographic -vga none -M ppce500 -smp 2 -m 4G -accel
>> tcg -kernel ./vmlinux -nic user -initrd ./ppc64-novsx-rootfs.cpio.gz
>> -cpu e5500 -append "noreboot"
>>
>>
>> Root cause:
>> The MAX_FOLIO_ORDER  for e500 platform is MAX_PAGE_ORDER which is
>> nothing but CONFIG_ARCH_FORCE_MAX_ORDER which dependent of page-size
>> which was 4k. So value of MAX_FOLIO_ODER is 12 for this case.
>>
>> As per arch/powerpc/mm/nohash/tlb.c the following page size are 
>> supported on
>> e500 platform:
>>
>> struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT] = {
>>       [MMU_PAGE_4K] = {
>>           .shift    = 12,
>>       },
>>       [MMU_PAGE_2M] = {
>>           .shift    = 21,
>>       },
>>       [MMU_PAGE_4M] = {
>>           .shift    = 22,
>>       },
>>       [MMU_PAGE_16M] = {
>>           .shift    = 24,
>>       },
>>       [MMU_PAGE_64M] = {
>>           .shift    = 26,
>>       },
>>       [MMU_PAGE_256M] = {
>>           .shift    = 28,
>>       },
>>       [MMU_PAGE_1G] = {
>>           .shift    = 30,
>>       },
>> };
>>
>> With the above MAX_FOLIO_ORDER and page sizes, hugetlbpage_init() in
>> arch/powerpc/mm/hugetlbpage.c tries to call hugetlb_add_hstate() with
>> an order higher than 12, causing the kernel to print the above warning.
>>
>> Things I tried:
>> I enabled CONFIG_ARCH_HAS_GIGANTIC_PAGE for the e500 platform. With that,
>> MAX_FOLIO_ORDER was set to 16, but that was not sufficient for 
>> MMU_PAGE_1G.
>>
>> This is because with CONFIG_ARCH_HAS_GIGANTIC_PAGE enabled,
>> MAX_FOLIO_ORDER was set to 16 = PUD_ORDER = (PMD_INDEX_SIZE (7) +
>> PTE_INDEX_SIZE (9)),
>> while the order for MMU_PAGE_1G was 18.
> 
> 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.

By the way, you would describe the fix better than me so yes if you can 
prepare and send a fix please do.

Christophe