From: Kaitao Cheng <kaitao.cheng@linux.dev>
To: Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>
Cc: Mani Tofigh <mt4022@columbia.edu>, Zi Yan <ziy@nvidia.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Frank van der Linden <fvdl@google.com>,
Chris Down <chris@chrisdown.name>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Kaitao Cheng <chengkaitao@kylinos.cn>
Subject: [PATCH v3 3/4] mm/hugetlb: fix NR_HUGETLB accounting for unused surplus folios
Date: Fri, 6 Nov 2026 18:05:20 +0800 [thread overview]
Message-ID: <20261106100521.30099-4-kaitao.cheng@linux.dev> (raw)
In-Reply-To: <20261106100521.30099-1-kaitao.cheng@linux.dev>
From: Kaitao Cheng <chengkaitao@kylinos.cn>
free_huge_folio() unconditionally decrements NR_HUGETLB, but freshly
allocated surplus folios can be freed before the counter has been
incremented.
This happens when alloc_surplus_hugetlb_folio() rejects a fresh folio
after its second surplus limit check. It also happens when
gather_surplus_pages() frees folios because a reservation cannot be
satisfied, or because concurrent pool changes leave excess folios
after the reservation succeeds.
These paths leave unmatched decrements, causing HugeTLB usage to be
underreported and potentially underflowing the counter.
Increment NR_HUGETLB before calling free_huge_folio() in both paths
to balance its unconditional decrement.
Fixes: 05d4532b60e3 ("memcg/hugetlb: add hugeTLB counters to memcg")
Closes: https://sashiko.dev/#/bug/linux-860a3b8f-0b07-4cd5-a122-aa2288463bee
Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
---
mm/hugetlb.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5b5353ff5ee2..31a92ed4165a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2140,6 +2140,8 @@ static struct folio *alloc_surplus_hugetlb_folio(struct hstate *h,
if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
folio_set_hugetlb_temporary(folio);
spin_unlock_irq(&hugetlb_lock);
+ /* Balance the NR_HUGETLB decrement in free_huge_folio(). */
+ lruvec_stat_mod_folio(folio, NR_HUGETLB, pages_per_huge_page(h));
free_huge_folio(folio);
return NULL;
}
@@ -2384,9 +2386,13 @@ static int gather_surplus_pages(struct hstate *h, long delta)
/*
* Free unnecessary surplus pages to the buddy allocator.
* Pages have no ref count, call free_huge_folio directly.
+ * These pages were not accounted in NR_HUGETLB, so balance the
+ * decrement in free_huge_folio().
*/
- list_for_each_entry_safe(folio, tmp, &surplus_list, lru)
+ list_for_each_entry_safe(folio, tmp, &surplus_list, lru) {
+ lruvec_stat_mod_folio(folio, NR_HUGETLB, pages_per_huge_page(h));
free_huge_folio(folio);
+ }
spin_lock_irq(&hugetlb_lock);
return ret;
--
2.53.0
next prev parent reply other threads:[~2026-11-06 10:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 10:05 [PATCH v3 0/4] Subject: [PATCH v3 0/4] mm/hugetlb: Fix CMA parsing, flags and usage accounting Kaitao Cheng
2026-11-06 10:05 ` [PATCH v3 1/4] mm/hugetlb_cma: fix incorrect hugetlb_cma_size assignment on malformed input Kaitao Cheng
2026-11-06 10:05 ` [PATCH v3 2/4] mm/hugetlb: Preserve persistent flags when returning folios to the pool Kaitao Cheng
2026-11-06 10:05 ` Kaitao Cheng [this message]
2026-11-06 10:05 ` [PATCH v3 4/4] mm/hugetlb: Account NR_HUGETLB at folio state transitions Kaitao Cheng
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=20261106100521.30099-4-kaitao.cheng@linux.dev \
--to=kaitao.cheng@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=cgroups@vger.kernel.org \
--cc=chengkaitao@kylinos.cn \
--cc=chris@chrisdown.name \
--cc=david@kernel.org \
--cc=fvdl@google.com \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=mt4022@columbia.edu \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=ziy@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®