From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.175 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793959576; b=bOs6irXAVixqsZlf8W8Xn6NGIxsSAvjyO1UWrggPymHkCsqCESGSYoTHKWZy66dWy9aB CWcXdGUBehQNQXKHy33VaV/2rZYmNeYG6DsZrIUbp7r2/CRwB4Q+2GRFyUNYRoYzjq1Rv Eym+7LWhlK6sBAsdFUCvY2H06Nxj6r2KpMcqaPS8+qGz5Xx3S4znUNmy0ZD25XIs8Qc3A IUxi1cuAq27kaTqUYHAYktKmEuNWy34NzxLeBL1t1naOCTuGi9ARKW1iZ3hDGFZaqVogZ Dvgwu+O3CEXt5wbZVSzqP3LEszLwRM7X7g7e0L9yl6QdXWxxOkhZNVYEON7zAVptu8w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793959576; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding; bh=84LIFW+AvMdbqkXSFm047CRtvQ9GP0clJy2Lqj2p5f8=; b=ISGwAorhGtwt3++AqMdYNjpi2JWHjd5Db9Mzn4JbTqk2Q/vV/s4ZhzU0Kirw2fn2xqQK kVV/fQnw9hNtVOfdRWTgabbuQq98gWFjFszjER77eeJqaT6ZFtTi89d4cGYkEG6MSwl2C CsuCVpZpfOY0auhO5nIYhcvzMNNemdZxHGMnijsuSYmAqtTnU0oq2s74aGqSdRU0OjFmI RNX8nJA8BOKHkMPpX+5BXxg6qDVpnfIZfO7SYWK17+RcU6kt3mfRjDd9aiOj4g71zCGPV QIari2v7B0jq6AQqwj0gwBS4quhbpxq8TygOEpl/UOKkS973l7JQ5N+5nI3FAIL+pAQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=IgGruhZp; arc=none smtp.remote-ip=95.215.58.175 Received: from mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A842A606A326 for ; Fri, 6 Nov 2026 10:06:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org A842A606A326 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=IgGruhZp X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=9W5E0aTicTRcozWJfG/+L+M5IQx5AOnpXJfN4HLzHSs=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793959573; v=1; x=1794564373; b=IgGruhZpDLOXxyBCxUc7kPAa24gzvdY3E3hdfzGfdTdUF5ff7hZXhd4gSLMyKUpOSbrQP6Zf A+cK0kK2jrHRc0rpNtXRDqRn6YgJbPa/LSybGQBsev36mKcNlQAuY5MvKiDojbJROMFhJ1+h1ja yuudZFpe8iHYu9T0U5jnUa44= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 9dea5587c19e644f; Fri, 06 Nov 2026 10:06:13 +0000 X-Mizu-Trace-ID: 9dea5587c19e644f X-Migadu-Flow: FLOW_OUT From: Kaitao Cheng To: Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Mike Rapoport , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt Cc: Mani Tofigh , Zi Yan , Mike Kravetz , Baolin Wang , Miaohe Lin , Naoya Horiguchi , Frank van der Linden , Chris Down , Joshua Hahn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Kaitao Cheng Subject: [PATCH v3 3/4] mm/hugetlb: fix NR_HUGETLB accounting for unused surplus folios Date: Fri, 6 Nov 2026 18:05:20 +0800 Message-ID: <20261106100521.30099-4-kaitao.cheng@linux.dev> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20261106100521.30099-1-kaitao.cheng@linux.dev> References: <20261106100521.30099-1-kaitao.cheng@linux.dev> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Kaitao Cheng 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 --- 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