Re: [PATCH 1/1] mm/hugetlb: keep max_huge_pages when dissolving surplus folios

[Longlong Xia <xialonglong2025@163.com>]

Hi Andrew,


I'd suggest backporting this. cb402bbdabca reached mainline in v6.14
and the -stable branches from v6.14.1 on (6.14.y–7.1.y), so those
carry the max_huge_pages corruption;

The fix is four lines on two accounting spots, low risk.


在 2026/8/15 2:40, Andrew Morton 写道:
> On Fri, 14 Aug 2026 16:30:27 +0800 Longlong Xia<xialonglong2025@163.com> wrote:
>
>> From: Longlong Xia<xialonglong@kylinos.cn>
>>
>> dissolve_free_hugetlb_folio() can remove a free folio as surplus when
>> its node has surplus pages.  In that case remove_hugetlb_folio()
>> decrements both nr_huge_pages and surplus_huge_pages, leaving the
>> persistent pool size unchanged.
>>
>> Updating max_huge_pages as if a persistent folio had been removed can
>> therefore corrupt the persistent pool target and underflow it when
>> max_huge_pages is zero.  Keep max_huge_pages unchanged for surplus
>> folios, including the vmemmap restoration rollback path.
> Thanks.
>
>> Fixes: cb402bbdabca ("mm/hugetlb: fix surplus pages in dissolve_free_huge_page()")
> That's a year old, so I'm assuming there's no urgency here.  I'll
> save the fix for later and shall await maintainer input.  While at it,
> please suggest whether we should backport this.
>
> AI review might have found a couple of bugs in the surrounding code.  If true,
> they look rather nasty.
>
> 	https://sashiko.dev/#/patchset/20260814083027.1419487-1-xialonglong2025@163.com

The AI findings are real but pre-existing:
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. I will send separately fix patch.


Thanks，
Longlong