[PATCH v2 0/2] mm/hugetlb: dissolve gigantic pages without runtime support

[PATCH v2 0/2] mm/hugetlb: dissolve gigantic pages without runtime support

[Longlong Xia]

From: Longlong Xia <xialonglong@kylinos.cn>

v2 of the dissolve fix. It now carries the cleanup David asked for as a
separate patch, and is split so the minimal bug fix can go to -stable on
its own.

  1/2 - mm/hugetlb: do not dissolve gigantic pages without runtime support
        dissolve_free_hugetlb_folio() doesn't check
        hstate_is_gigantic_no_runtime(h); the helpers bail for such
        hstates, so dissolving leaves the folio on the free list and the
        add_hugetlb_folio() rollback on vmemmap restore failure corrupts
        that list. Bail out before touching the accounting. (Fixes,
        -stable candidate.)

  2/2 - mm/hugetlb: warn instead of silently bailing gigantic pages
        without runtime support
        Per David's review: turn the silent bail in
        remove_hugetlb_folio()/__update_and_free_hugetlb_folio() into a
        VM_WARN_ON_ONCE. All callers already filter
        gigantic_no_runtime upstream. (no Fixes, -next only.)

Changes in v2 (vs the single v1 patch):
  - Split into [1/2] bug fix and [2/2] cleanup so the fix stays minimal
    for -stable and the diagnostic cleanup is -next only.
  - [2/2] is new, per David's review ("VM_WARN_ON() instead of handling
    it silently").
  - [1/2] differs from v1 only by a comment reword.

Link: https://lore.kernel.org/r/20260817162039.1511838-1-xialonglong2025@163.com
Link: https://sashiko.dev/#/patchset/20260814083027.1419487-1-xialonglong2025@163.com

Longlong Xia (2):
  mm/hugetlb: do not dissolve gigantic pages without runtime support
  mm/hugetlb: warn instead of silently bailing gigantic pages without
    runtime support

 mm/hugetlb.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH v2 1/2] mm/hugetlb: do not dissolve gigantic pages without runtime support

[Longlong Xia]

From: Longlong Xia <xialonglong@kylinos.cn>

dissolve_free_hugetlb_folio() doesn't check
hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/
update_and_free_hugetlb_folio() silently bail for such folios, so it
frees a still-listed folio and, on vmemmap restore failure, the
add_hugetlb_folio() rollback corrupts the free list.

Fixes: 6eb4e88a6d27 ("hugetlb: create remove_hugetlb_page() to separate functionality")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
---
 mm/hugetlb.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index e93c4d2456aa..8b9cb476a41b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1977,6 +1977,15 @@ int dissolve_free_hugetlb_folio(struct folio *folio)
 		struct hstate *h = folio_hstate(folio);
 		bool adjust_surplus = false;
 
+		/*
+		 * remove_hugetlb_folio()/update_and_free_hugetlb_folio() bail
+		 * for gigantic hstates without runtime support, so dissolving one
+		 * here would leave it on the free list and, on vmemmap restore
+		 * failure, the add_hugetlb_folio() rollback corrupts that list.
+		 */
+		if (hstate_is_gigantic_no_runtime(h))
+			goto out;
+
 		if (!available_huge_pages(h))
 			goto out;
 
-- 
2.43.0

Re: [PATCH v2 1/2] mm/hugetlb: do not dissolve gigantic pages without runtime support

[Andrew Morton]

On Sun, 23 Aug 2026 12:40:51 +0800 Longlong Xia <xialonglong2025@163.com> wrote:

> From: Longlong Xia <xialonglong@kylinos.cn>
> 
> dissolve_free_hugetlb_folio() doesn't check
> hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/
> update_and_free_hugetlb_folio() silently bail for such folios, so it
> frees a still-listed folio and, on vmemmap restore failure, the
> add_hugetlb_folio() rollback corrupts the free list.
> 
> Fixes: 6eb4e88a6d27 ("hugetlb: create remove_hugetlb_page() to separate functionality")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>

This doesn't carry an explicit cc:stable, as you mentioned in the cover
letter.  And that's OK - people often omit it.  Perhaps because the
-stable people backport every dang thing which has a Fixes:.  They've
been asked not to do that for MM.

Also, the changelogging doesn't provide reasons for backporting the
fix.  Please review Documentation/process/stable-kernel-rules.rst.  The
key thing is to include a description of the userspace-visible runtime
effects of the bug.

A reproducer, a Reported-by:, a Closes:, etc.  *something* to explain
to people why they should make this change to their kernel.

From the v1 review discussion it appears that this fix was inspired by
a Sashiko report?  Changelogging this detail would be helpful.


I asked Gemini to create a reproducer for this
(https://share.gemini.google/be2PvvOLw6kx) and it's very involved. 
Makes me suspect that nobody has hit this in real life?


Muchun's ack wasn't carried over from the v1 patch?


Thanks, I'll apply the patches (hoping for additional review) but at
this stage I'm not really sure *why* I"m applying them!


btw, there wasn't anything in the [0/N] cover letter which was usable
in a cover letter.  But that's OK - I'll split the series apart anyway
Because [1/1] is cc:stable so it will take a different path into
mainline, with different timing.


hm, anyway, that was lengthy.  Please send along a few additional words
telling people why we feel this should be backported?

Re: [PATCH v2 1/2] mm/hugetlb: do not dissolve gigantic pages without runtime support

[Muchun Song]

> On Aug 23, 2026, at 12:40, Longlong Xia <xialonglong2025@163.com> wrote:
> 
> From: Longlong Xia <xialonglong@kylinos.cn>
> 
> dissolve_free_hugetlb_folio() doesn't check
> hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/
> update_and_free_hugetlb_folio() silently bail for such folios, so it
> frees a still-listed folio and, on vmemmap restore failure, the
> add_hugetlb_folio() rollback corrupts the free list.
> 
> Fixes: 6eb4e88a6d27 ("hugetlb: create remove_hugetlb_page() to separate functionality")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>

Again.

Acked-by: Muchun Song <muchun.song@linux.dev>

Thanks.

[PATCH v2 2/2] mm/hugetlb: warn instead of silently bailing gigantic pages without runtime support

[Longlong Xia]

From: Longlong Xia <xialonglong@kylinos.cn>

remove_hugetlb_folio() and __update_and_free_hugetlb_folio() silently
return for gigantic hstates that lack runtime freeing support. All
callers should already filter such hstates upstream, so turn the
silent bail into a VM_WARN_ON_ONCE to catch caller regressions
instead of masking them.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
---
 mm/hugetlb.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8b9cb476a41b..67a502293698 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1398,8 +1398,11 @@ void remove_hugetlb_folio(struct hstate *h, struct folio *folio,
 	VM_BUG_ON_FOLIO(hugetlb_cgroup_from_folio_rsvd(folio), folio);
 
 	lockdep_assert_held(&hugetlb_lock);
-	if (hstate_is_gigantic_no_runtime(h))
+	if (hstate_is_gigantic_no_runtime(h)) {
+		/* Callers must filter gigantic_no_runtime upstream. */
+		VM_WARN_ON_ONCE(1);
 		return;
+	}
 
 	list_del(&folio->lru);
 
@@ -1460,8 +1463,11 @@ static void __update_and_free_hugetlb_folio(struct hstate *h,
 {
 	bool clear_flag = folio_test_hugetlb_vmemmap_optimized(folio);
 
-	if (hstate_is_gigantic_no_runtime(h))
+	if (hstate_is_gigantic_no_runtime(h)) {
+		/* Callers must filter gigantic_no_runtime upstream. */
+		VM_WARN_ON_ONCE(1);
 		return;
+	}
 
 	/*
 	 * If we don't know which subpages are hwpoisoned, we can't free
-- 
2.43.0

Re: [PATCH v2 2/2] mm/hugetlb: warn instead of silently bailing gigantic pages without runtime support

[Muchun Song]

> On Aug 23, 2026, at 12:40, Longlong Xia <xialonglong2025@163.com> wrote:
> 
> From: Longlong Xia <xialonglong@kylinos.cn>
> 
> remove_hugetlb_folio() and __update_and_free_hugetlb_folio() silently
> return for gigantic hstates that lack runtime freeing support. All
> callers should already filter such hstates upstream, so turn the
> silent bail into a VM_WARN_ON_ONCE to catch caller regressions
> instead of masking them.
> 
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>

Acked-by: Muchun Song <muchun.song@linux.dev>

Thanks.