From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Jinmeng Zhou <jinmengzhou22@gmail.com>,
Jinmeng Zhou <zhoujinmeng@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
Hongfu Li <lihongfu@kylinos.cn>,
David Hildenbrand <david@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>, Nhat Pham <nphamcs@gmail.com>,
Oscar Salvador <osalvador@suse.de>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.12.y] mm/hugetlb: charge folios to the target mm's memcg
Date: Tue, 10 Nov 2026 22:47:52 -0500 [thread overview]
Message-ID: <20261111034526.953066-1-sashal@kernel.org> (raw)
In-Reply-To: <20261107052023-failed-6.12-c2deb1356d82@kernel.org>
From: Jinmeng Zhou <jinmengzhou22@gmail.com>
[ Upstream commit c2deb1356d82c9d54bd2fcf1241cc97eb66fd81f ]
HugeTLB folios are currently charged to the memcg of the allocating task.
This gives the wrong result when a userfaultfd handler populates a HugeTLB
VMA that belongs to another process. The UFFDIO_COPY ioctl operates on
the userfaultfd context's mm, but get_mem_cgroup_from_current() charges
the folio to the handler's memcg instead.
This can be reproduced by placing the faulting process and its userfaultfd
handler in different memory cgroups. Have the target process register a
HugeTLB mapping with userfaultfd, trigger a missing fault, and let the
handler resolve it with UFFDIO_COPY. The hugepage usage is then reported
in the handler's memory.current instead of the target's.
The generic userfaultfd population path avoids this problem by charging
folios to dst_vma->vm_mm.
Pass the target mm through hugetlb_alloc_folio() and charge the folio by
using get_mem_cgroup_from_mm(). This preserves the existing charge timing
and error handling while making HugeTLB userfaultfd population consistent
with the generic path.
Link: https://lore.kernel.org/20260903075048.3316-1-zhoujinmeng@bytedance.com
Fixes: 8cba9576df60 ("hugetlb: memcg: account hugetlb-backed memory in memory controller")
Signed-off-by: Jinmeng Zhou <zhoujinmeng@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Reviewed-by: Hongfu Li <lihongfu@kylinos.cn>
Cc: David Hildenbrand <david@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: <stable@vger.kernel.org>
[ sashal: Used vma->vm_mm directly in alloc_hugetlb_folio() instead of passing it through the unavailable upstream helpers. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d9443bdebc068..c60696b68462e 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3013,7 +3013,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma,
bool deferred_reserve;
gfp_t gfp = htlb_alloc_mask(h) | __GFP_RETRY_MAYFAIL;
- memcg = get_mem_cgroup_from_current();
+ memcg = get_mem_cgroup_from_mm(vma->vm_mm);
memcg_charge_ret = mem_cgroup_hugetlb_try_charge(memcg, gfp, nr_pages);
if (memcg_charge_ret == -ENOMEM) {
mem_cgroup_put(memcg);
--
2.53.0
prev parent reply other threads:[~2026-11-11 3:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 10:20 FAILED: patch "[PATCH] mm/hugetlb: charge folios to the target mm's memcg" failed to apply to 6.12-stable tree Sasha Levin
2026-11-11 3:47 ` Sasha Levin [this message]
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=20261111034526.953066-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jinmengzhou22@gmail.com \
--cc=lihongfu@kylinos.cn \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=nphamcs@gmail.com \
--cc=osalvador@suse.de \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--cc=zhoujinmeng@bytedance.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