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

[David Hildenbrand]

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?

[1] 
https://lkml.kernel.org/r/4632e721-0ac8-4d72-a8ed-e6c928eee94d@csgroup.eu

-- 
Cheers

David / dhildenb