mm/hugetlb: do not dissolve gigantic pages without runtime support

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://lore.kernel.org/20260823044118.1097121-2-xialonglong2025@163.com
Fixes: 6eb4e88a6d ("hugetlb: create remove_hugetlb_page() to separate functionality")
Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Assisted-by: Codex:gpt-5.6-sol
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@kernel.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: <stable@vger.kernel.org>
This commit is contained in:
Longlong Xia 2026-08-23 12:40:51 +08:00 committed by Andrew Morton
parent 7891fbb951
commit a363c62a65

View File

@ -1967,6 +1967,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;