[PATCH v7] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[PATCH v7] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sourabh Jain]

Skip processing hugepage kernel arguments (hugepagesz, hugepages, and
default_hugepagesz) when hugepages are not supported by the
architecture.

Some architectures may need to disable hugepages based on conditions
discovered during kernel boot. The hugepages_supported() helper allows
architecture code to advertise whether hugepages are supported.

Currently, normal hugepage allocation is guarded by
hugepages_supported(), but gigantic hugepages are allocated regardless
of this check. This causes problems on powerpc for fadump (firmware-
assisted dump).

In the fadump (firmware-assisted dump) scenario, a production kernel
crash causes the system to boot into a special kernel whose sole
purpose is to collect the memory dump and reboot. Features such as
hugepages are not required in this environment and should be
disabled.

For example, when the fadump kernel boots with the following kernel
arguments:
default_hugepagesz=1GB hugepagesz=1GB hugepages=200

Before this patch, the kernel prints the following logs:

 HugeTLB: allocating 200 of page size 1.00 GiB failed.  Only allocated 58 hugepages.
 HugeTLB support is disabled!
 HugeTLB: huge pages not supported, ignoring associated command-line parameters
 hugetlbfs: disabling because there are no supported hugepage sizes

Even though the logs state that HugeTLB support is disabled, gigantic
hugepages are still allocated. This causes the fadump kernel to run out
of memory during boot.

After this patch is applied, the kernel prints the following logs for
the same command line:

 HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline
 HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline
 HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline
 HugeTLB support is disabled!
 hugetlbfs: disabling because there are no supported hugepage sizes

To fix the issue, gigantic hugepage allocation should be guarded by
hugepages_supported().

Previously, two approaches were proposed to bring gigantic hugepage
allocation under hugepages_supported():

[1] Check hugepages_supported() in the generic code before allocating
gigantic hugepages
[2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes

Approach [2] has two minor issues:
1. It prints misleading logs about invalid hugepage sizes
2. The kernel still processes hugepage kernel arguments unnecessarily

To control gigantic hugepage allocation, skip processing hugepage kernel
arguments (default_hugepagesz, hugepagesz and hugepages) when
hugepages_supported() returns false.

Note for backporting: This fix is a partial retrieval of the commit
mentioned in the Fixes tag and is only valid once the change referenced
by the Depends-on tag is present. When backporting this patch, the
commit mentioned in the Depends-on tag must be included first.

Note for backporting: This fix is a partial retrieval of the commit
mentioned in the Fixes tag. It is only valid once the change referenced
by the Depends-on tag is present. When backporting this patch, the
commit mentioned in the Depends-on tag must be included first.

Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1]
Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2]
Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
Depends-on: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: linux-mm@kvack.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-riscv@lists.infradead.org
Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
Changelog:

v1:
https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/

v2:
https://lore.kernel.org/all/20250124103220.111303-1-sourabhjain@linux.ibm.com/
 - disable gigantic hugepage in arch code, arch_hugetlb_valid_size()

v3:
https://lore.kernel.org/all/20250125104928.88881-1-sourabhjain@linux.ibm.com/
 - Do not modify the initialization of the shift variable

v4:
https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/
 - Update commit message to include how hugepages_supported() detects
   hugepages support when fadump is active
 - Add Reviewed-by tag
 - NO functional change

v5:
https://lore.kernel.org/all/20251218114154.228484-1-sourabhjain@linux.ibm.com/
 - Significant change in approach: disable processing of hugepage kernel
   arguments if hugepages_supported() returns false
 - Drop a Reviewed-by tag

v6:
https://lore.kernel.org/all/20251221053611.441251-1-sourabhjain@linux.ibm.com/
 - Updated commit message with additional logs and tags
 - No functional changes

v7:
 - Add a note for backporting this fix in the commit message
 - Add a Depends-on tag referencing the prerequisite commit
 - No functional changes
---
 mm/hugetlb.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 51273baec9e5..e0ab14020513 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4286,6 +4286,11 @@ static int __init hugepages_setup(char *s)
 	unsigned long tmp;
 	char *p = s;
 
+	if (!hugepages_supported()) {
+		pr_warn("HugeTLB: hugepages unsupported, ignoring hugepages=%s cmdline\n", s);
+		return 0;
+	}
+
 	if (!parsed_valid_hugepagesz) {
 		pr_warn("HugeTLB: hugepages=%s does not follow a valid hugepagesz, ignoring\n", s);
 		parsed_valid_hugepagesz = true;
@@ -4366,6 +4371,11 @@ static int __init hugepagesz_setup(char *s)
 	unsigned long size;
 	struct hstate *h;
 
+	if (!hugepages_supported()) {
+		pr_warn("HugeTLB: hugepages unsupported, ignoring hugepagesz=%s cmdline\n", s);
+		return 0;
+	}
+
 	parsed_valid_hugepagesz = false;
 	size = (unsigned long)memparse(s, NULL);
 
@@ -4414,6 +4424,12 @@ static int __init default_hugepagesz_setup(char *s)
 	unsigned long size;
 	int i;
 
+	if (!hugepages_supported()) {
+		pr_warn("HugeTLB: hugepages unsupported, ignoring default_hugepagesz=%s cmdline\n",
+			s);
+		return 0;
+	}
+
 	parsed_valid_hugepagesz = false;
 	if (parsed_default_hugepagesz) {
 		pr_err("HugeTLB: default_hugepagesz previously specified, ignoring %s\n", s);
-- 
2.51.1

Re: [PATCH v7] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Andrew Morton]

On Wed, 24 Dec 2025 17:25:24 +0530 Sourabh Jain <sourabhjain@linux.ibm.com> wrote:

> Note for backporting: This fix is a partial retrieval of the commit
> mentioned in the Fixes tag. It is only valid once the change referenced
> by the Depends-on tag is present. When backporting this patch, the
> commit mentioned in the Depends-on tag must be included first.
> 
> Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1]
> Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2]
> Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
> Depends-on: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early")

This will be the first "Depends-on:" in history.  Which is a hint that
we're doing something wrong.  This innovation will surely fool any
downstream automation.  Let's use existing tools if possible.

What if we just said "Fixes: 2354ad252b66"?  That would tell people
that 2354ad252b66 is required for use of this patch.

Is there any kernel which has 2354ad252b66 but which doesn't have
c2833a5bf75b?  Probably there is, as neither had cc:stable.

2354ad252b66 is from 2020 and c2833a5bf75b is from 2022.  I'm thinking
the reliable thing to do here is to simply use Fixes:c2833a5bf75b. 
This will tell the world "please add this patch to any kernel which
contains c2833a5bf75b", which I suspect will be good enough?

Re: [PATCH v7] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Christophe Leroy (CS GROUP)]

Le 28/12/2025 à 23:35, Andrew Morton a écrit :
> On Wed, 24 Dec 2025 17:25:24 +0530 Sourabh Jain <sourabhjain@linux.ibm.com> wrote:
> 
>> Note for backporting: This fix is a partial retrieval of the commit
>> mentioned in the Fixes tag. It is only valid once the change referenced
>> by the Depends-on tag is present. When backporting this patch, the
>> commit mentioned in the Depends-on tag must be included first.
>>
>> Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20250121150419.1342794-1-sourabhjain%40linux.ibm.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C93a8f925fc024ff9c3fe08de46616c3b%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639025581404027066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3iVUdaMBWhExKkDiV%2BBfYufPTKva1dVikhyQShOq7mc%3D&reserved=0 [1]
>> Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20250128043358.163372-1-sourabhjain%40linux.ibm.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C93a8f925fc024ff9c3fe08de46616c3b%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639025581404053206%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GamDe2R87SdpFurnj9Cmt9wOQtkGLgIO1z7nl5QPxgY%3D&reserved=0 [2]
>> Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
>> Depends-on: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early")
> 
> This will be the first "Depends-on:" in history.  Which is a hint that
> we're doing something wrong.  This innovation will surely fool any
> downstream automation.  Let's use existing tools if possible.

What do you mean by "first in history" ? Do you mean it's never been 
used before ? As far as I can see it has been used several times 
already. First one was in 2014 with commit a0855054e59b ("iwlwifi: dvm: 
drop non VO frames when flushing")

Sasha, do tools use it ?

$ git log | grep "Depends-on: " | wc -l
137

$ git log | grep "Depends-on: " | head -10
     Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
     Depends-on: arm64: dts: nuvoton: Combine NPCM845 reset and clk nodes
     Depends-on: 058518c20920 ("landlock: Align partial refer access 
checks with final ones")
     Depends-on: d617f0d72d80 ("landlock: Optimize file path walks and 
prepare for audit support")
     Depends-on: 7ccbe076d987 ("lsm: Only build lsm_audit.c if 
CONFIG_SECURITY and CONFIG_AUDIT are set")
     Depends-on: 26f204380a3c ("fs: Fix file_set_fowner LSM hook 
inconsistencies")
     Depends-on: commit 045b14ca5c36 ("of: WARN on deprecated 
#address-cells/#size-cells handling")
     Depends-on: v6.12+ with PREEMPT_RT enabled
     Depends-on: 045b14ca5c36 ("of: WARN on deprecated 
#address-cells/#size-cells handling")
     Depends-on: commit aec89dc5d421 ("block: keep q_usage_counter in 
atomic mode after del_gendisk")

Christophe

Re: [PATCH v7] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sasha Levin]

On Mon, Dec 29, 2025 at 07:35:18PM +0100, Christophe Leroy (CS GROUP) wrote:
>
>
>Le 28/12/2025 à 23:35, Andrew Morton a écrit :
>>On Wed, 24 Dec 2025 17:25:24 +0530 Sourabh Jain <sourabhjain@linux.ibm.com> wrote:
>>
>>>Note for backporting: This fix is a partial retrieval of the commit
>>>mentioned in the Fixes tag. It is only valid once the change referenced
>>>by the Depends-on tag is present. When backporting this patch, the
>>>commit mentioned in the Depends-on tag must be included first.
>>>
>>>Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20250121150419.1342794-1-sourabhjain%40linux.ibm.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C93a8f925fc024ff9c3fe08de46616c3b%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639025581404027066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3iVUdaMBWhExKkDiV%2BBfYufPTKva1dVikhyQShOq7mc%3D&reserved=0 [1]
>>>Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20250128043358.163372-1-sourabhjain%40linux.ibm.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C93a8f925fc024ff9c3fe08de46616c3b%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639025581404053206%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GamDe2R87SdpFurnj9Cmt9wOQtkGLgIO1z7nl5QPxgY%3D&reserved=0 [2]
>>>Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
>>>Depends-on: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early")
>>
>>This will be the first "Depends-on:" in history.  Which is a hint that
>>we're doing something wrong.  This innovation will surely fool any
>>downstream automation.  Let's use existing tools if possible.
>
>What do you mean by "first in history" ? Do you mean it's never been 
>used before ? As far as I can see it has been used several times 
>already. First one was in 2014 with commit a0855054e59b ("iwlwifi: 
>dvm: drop non VO frames when flushing")
>
>Sasha, do tools use it ?

The standard way to annotate dependencies is outlined in the docs:

   To send additional instructions to the stable team, use a shell-style inline comment to pass arbitrary or predefined notes:

   Specify any additional patch prerequisites for cherry picking:

   Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
   Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
   Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
   Cc: <stable@vger.kernel.org> # 3.3.x
   Signed-off-by: Ingo Molnar <mingo@elte.hu>

   The tag sequence has the meaning of:

   git cherry-pick a1f84a3
   git cherry-pick 1b9508f
   git cherry-pick fd21073
   git cherry-pick <this commit>

My tools don't look at Depends-on: and I don't think that Greg's tools do that
either.

-- 
Thanks,
Sasha