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

From: Longlong Xia <[email protected]>

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.

Link: https://sashiko.dev/#/patchset/[email protected]
Fixes: 6eb4e88a6d27 ("hugetlb: create remove_hugetlb_page() to separate functionality")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Longlong Xia <[email protected]>
---
 mm/hugetlb.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2239e2566a52..f8370da93647 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() are no-ops
+		 * 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