From: Andrew Morton <akpm@linux-foundation.org>
To: Longlong Xia <xialonglong2025@163.com>
Cc: Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Jinjiang Tu <tujinjiang@huawei.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Longlong Xia <xialonglong@kylinos.cn>
Subject: Re: [PATCH 1/1] mm/hugetlb: keep max_huge_pages when dissolving surplus folios
Date: Fri, 14 Aug 2026 11:40:59 -0700 [thread overview]
Message-ID: <20260814114059.c9fd2ef48f4f1b71a8b437f3@linux-foundation.org> (raw)
In-Reply-To: <20260814083027.1419487-1-xialonglong2025@163.com>
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
next prev parent reply other threads:[~2026-08-14 18:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 8:30 [PATCH 1/1] mm/hugetlb: keep max_huge_pages when dissolving surplus folios Longlong Xia
2026-08-14 18:40 ` Andrew Morton [this message]
2026-08-17 14:03 ` Longlong Xia
2026-08-15 3:54 ` Muchun Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260814114059.c9fd2ef48f4f1b71a8b437f3@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=tujinjiang@huawei.com \
--cc=xialonglong2025@163.com \
--cc=xialonglong@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.