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

[PATCH 1/1] 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.

Link: https://sashiko.dev/#/patchset/20260814083027.1419487-1-xialonglong2025@163.com
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 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

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

[Muchun Song]

> On Aug 18, 2026, at 00:20, 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.
> 
> Link: https://sashiko.dev/#/patchset/20260814083027.1419487-1-xialonglong2025@163.com
> 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>

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

Thanks.

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

[David Hildenbrand (Arm)]

On 8/17/26 18:20, Longlong Xia 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

That's odd. Why do they silently skip such folios instead of warning that
something unexpected is happening?

This screams for a cleanup unless I am missing something :)

-- 
Cheers,

David

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

[Longlong Xia]

在 2026/8/19 16:52, David Hildenbrand (Arm) 写道:
> On 8/17/26 18:20, Longlong Xia 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
> That's odd. Why do they silently skip such folios instead of warning that
> something unexpected is happening?
>
> This screams for a cleanup unless I am missing something :)
Because until this patch, dissolve_free_hugetlb_folio() was the one caller
that didn't filter hstate_is_gigantic_no_runtime() upstream. A WARN
would have fired on a real path: hotplug or hwpoison dissolving
a boot gigantic page on a no-runtime arch. So it had to stay silent.


This patch guards that last caller. The rest either check
hstate_is_gigantic_no_runtime() before calling, or operate on folios that
can't be gigantic_no_runtime (surplus/temporary gigantic folios aren't
created once alloc_gigantic_frozen_folio() returns NULL).

With the gap closed the bail can become a VM_WARN_ON_ONCE:

   // mm/hugetlb.c:1401  remove_hugetlb_folio
   if (hstate_is_gigantic_no_runtime(h)) {
+       /* Callers must filter gigantic_no_runtime upstream. */
+       VM_WARN_ON_ONCE(1);
         return;
   }

   // mm/hugetlb.c:1463  __update_and_free_hugetlb_folio
   if (hstate_is_gigantic_no_runtime(h)) {
+       /* Callers must filter gigantic_no_runtime upstream. */
+       VM_WARN_ON_ONCE(1);
         return;
   }

Separate follow-up, or fold into a v2 of this patch?

Thanks,

Longlong

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

[Muchun Song]

> On Aug 19, 2026, at 16:52, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> On 8/17/26 18:20, Longlong Xia 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
> 
> That's odd. Why do they silently skip such folios instead of warning that
> something unexpected is happening?
> 
> This screams for a cleanup unless I am missing something :)

Hi David,

Sashiko actually has a pretty detailed description [1]. So I think it deserves a fix.

[1] https://sashiko.dev/#/patchset/20260814083027.1419487-1-xialonglong2025@163.com

Muchun,
Thanks.

> 
> -- 
> Cheers,
> 
> David

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

[David Hildenbrand (Arm)]

On 8/20/26 11:38, Muchun Song wrote:
> 
> 
>> On Aug 19, 2026, at 16:52, David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>> On 8/17/26 18:20, Longlong Xia 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
>>
>> That's odd. Why do they silently skip such folios instead of warning that
>> something unexpected is happening?
>>
>> This screams for a cleanup unless I am missing something :)
> 
> Hi David,
> 
> Sashiko actually has a pretty detailed description [1]. So I think it deserves a fix.

That's not what I meant. I agree that its a valid fix, but I think the code
should possibly be reworked to not get silent rejection from these
functions--IOW, likely the callers should make sure to never call them in this
scenario, and then VM_WARN_ON() instead of handling it silently.


-- 
Cheers,

David