[PATCH] mm/hugetlb: fix validation of unsupported HugeTLB orders

[PATCH] mm/hugetlb: fix validation of unsupported HugeTLB orders

[Muchun Song]

Commit 7ce6048d3a7d ("loongarch: drop ranges for definition of
ARCH_FORCE_MAX_ORDER") removed the ARCH_FORCE_MAX_ORDER ranges for
LoongArch. Besides dropping unreasonable upper limits, this allowed
values below the architecture defaults.

With 16KB pages, LoongArch defaults ARCH_FORCE_MAX_ORDER to 11,
matching HUGETLB_PAGE_ORDER. Forcing it to 10 while enabling HugeTLB
permits order-11 HugeTLB folios even though MAX_FOLIO_ORDER is 10.
LoongArch does not select ARCH_HAS_GIGANTIC_PAGE, so this violates the
generic MM assumption that folios cannot exceed MAX_PAGE_ORDER.

This invalid configuration is accepted by Kconfig.
BUILD_BUG_ON_INVALID() does not reject it either because it only checks
whether the expression is valid and never evaluates the comparison.
Detection is left to the runtime warning in hugetlb_add_hstate(), after
earlier boot paths may already have used the invalid configuration.

When an invalid HugeTLB order can be identified at build time, reject it
there. Otherwise, reject it at runtime before the mismatch propagates
further. Use MAYBE_BUILD_BUG_ON() so constant violations fail the build
while dynamically determined orders are checked at runtime.

Fixes: 7ce6048d3a7d ("loongarch: drop ranges for definition of ARCH_FORCE_MAX_ORDER")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/sashiko-outbox-192874@kernel.org/
Suggested-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
---
 mm/hugetlb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ff9dbfbc7a96..e21ac667694b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4181,7 +4181,7 @@ static int __init hugetlb_init(void)
 
 	BUILD_BUG_ON(sizeof_field(struct page, private) * BITS_PER_BYTE <
 			__NR_HPAGEFLAGS);
-	BUILD_BUG_ON_INVALID(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);
+	MAYBE_BUILD_BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);
 
 	if (!hugepages_supported()) {
 		if (hugetlb_max_hstate || default_hstate_max_huge_pages)

base-commit: d42dfde37af766d1c272467352c0a56d3169ee58
-- 
2.54.0

Re: [PATCH] mm/hugetlb: fix validation of unsupported HugeTLB orders

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm/hugetlb: boot BUG_ON() in hugetlb_init() when HPAGE_SHIFT is 0 on powerpc
--

commit 83959b12982c256d20ca0de51021b3beae201569
Author: Muchun Song <muchun.song@linux.dev>

mm/hugetlb: fix validation of unsupported HugeTLB orders

This commit replaces BUILD_BUG_ON_INVALID() with MAYBE_BUILD_BUG_ON() in
hugetlb_init() so that configurations where HUGETLB_PAGE_ORDER exceeds
MAX_FOLIO_ORDER are rejected at build time when constant or via BUG_ON() at
runtime otherwise.

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ff9dbfbc7a961..e21ac667694bd 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4181,7 +4181,7 @@ static int __init hugetlb_init(void)
>  
>  	BUILD_BUG_ON(sizeof_field(struct page, private) * BITS_PER_BYTE <
>  			__NR_HPAGEFLAGS);
> -	BUILD_BUG_ON_INVALID(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);
> +	MAYBE_BUILD_BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);

[Severity: High]
Will placing MAYBE_BUILD_BUG_ON() before the hugepages_supported() check in
hugetlb_init() trigger a boot BUG_ON() on architectures like PowerPC
Book3S-64 when huge pages are unsupported at runtime?

On CONFIG_PPC_BOOK3S_64, arch/powerpc/include/asm/page.h defines HPAGE_SHIFT
as a runtime unsigned int variable:

    extern unsigned int hpage_shift;
    #define HPAGE_SHIFT hpage_shift
    ...
    #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)

Because hpage_shift is not a compile-time constant, MAYBE_BUILD_BUG_ON()
expands to a runtime BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER).

When huge pages are not supported by the platform or are disabled at boot
(for example, when hugetlbpage_init_defaultsize() in
arch/powerpc/mm/book3s64/hugetlbpage.c finds no supported huge page sizes),
hpage_shift remains 0, which hugepages_supported() checks:

    static inline bool hugepages_supported(void)
    {
            if (hugetlb_disabled)
                    return false;

            return HPAGE_SHIFT != 0;
    }

Evaluating HUGETLB_PAGE_ORDER before checking hugepages_supported() computes
(0U - PAGE_SHIFT) in unsigned int arithmetic, wrapping around to a large
unsigned value that exceeds MAX_FOLIO_ORDER and hits BUG_ON().

Should MAYBE_BUILD_BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER) be moved
after the if (!hugepages_supported()) block in hugetlb_init(), similar to how
hugepage_init() in mm/huge_memory.c checks has_transparent_hugepage() before
evaluating MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER > MAX_PAGE_ORDER)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103023831.1805473-1-songmuchun@bytedance.com?part=1

Re: [PATCH] mm/hugetlb: fix validation of unsupported HugeTLB orders

[Muchun Song]

> On Nov 3, 2026, at 16:13, sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] mm/hugetlb: boot BUG_ON() in hugetlb_init() when HPAGE_SHIFT is 0 on powerpc
> --
> 
> commit 83959b12982c256d20ca0de51021b3beae201569
> Author: Muchun Song <muchun.song@linux.dev>
> 
> mm/hugetlb: fix validation of unsupported HugeTLB orders
> 
> This commit replaces BUILD_BUG_ON_INVALID() with MAYBE_BUILD_BUG_ON() in
> hugetlb_init() so that configurations where HUGETLB_PAGE_ORDER exceeds
> MAX_FOLIO_ORDER are rejected at build time when constant or via BUG_ON() at
> runtime otherwise.
> 
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index ff9dbfbc7a961..e21ac667694bd 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4181,7 +4181,7 @@ static int __init hugetlb_init(void)
>> 
>> 	BUILD_BUG_ON(sizeof_field(struct page, private) * BITS_PER_BYTE <
>> 			__NR_HPAGEFLAGS);
>> -	BUILD_BUG_ON_INVALID(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);
>> +	MAYBE_BUILD_BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);
> 
> [Severity: High]
> Will placing MAYBE_BUILD_BUG_ON() before the hugepages_supported() check in
> hugetlb_init() trigger a boot BUG_ON() on architectures like PowerPC
> Book3S-64 when huge pages are unsupported at runtime?

Yeah, it's easy to fix, but I'll wait another day before updating it—just
in case others have feedback.

Thanks,
Muchun

> 
> On CONFIG_PPC_BOOK3S_64, arch/powerpc/include/asm/page.h defines HPAGE_SHIFT
> as a runtime unsigned int variable:
> 
>    extern unsigned int hpage_shift;
>    #define HPAGE_SHIFT hpage_shift
>    ...
>    #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
> 
> Because hpage_shift is not a compile-time constant, MAYBE_BUILD_BUG_ON()
> expands to a runtime BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER).
> 
> When huge pages are not supported by the platform or are disabled at boot
> (for example, when hugetlbpage_init_defaultsize() in
> arch/powerpc/mm/book3s64/hugetlbpage.c finds no supported huge page sizes),
> hpage_shift remains 0, which hugepages_supported() checks:
> 
>    static inline bool hugepages_supported(void)
>    {
>            if (hugetlb_disabled)
>                    return false;
> 
>            return HPAGE_SHIFT != 0;
>    }
> 
> Evaluating HUGETLB_PAGE_ORDER before checking hugepages_supported() computes
> (0U - PAGE_SHIFT) in unsigned int arithmetic, wrapping around to a large
> unsigned value that exceeds MAX_FOLIO_ORDER and hits BUG_ON().
> 
> Should MAYBE_BUILD_BUG_ON(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER) be moved
> after the if (!hugepages_supported()) block in hugetlb_init(), similar to how
> hugepage_init() in mm/huge_memory.c checks has_transparent_hugepage() before
> evaluating MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER > MAX_PAGE_ORDER)?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261103023831.1805473-1-songmuchun@bytedance.com?part=1