FAILED: patch "[PATCH] mm/huge_memory: use folio's memcg inside __folio_split()" failed to apply to 6.6-stable tree

FAILED: patch "[PATCH] mm/huge_memory: use folio's memcg inside __folio_split()" failed to apply to 6.6-stable tree

[gregkh]

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x c299a2285d9d8bda4da024455de65e3d00de6f17
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026090357-daybed-breach-27b2@gregkh' --subject-prefix 'PATCH 6.6.y' 'HEAD^..'

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From c299a2285d9d8bda4da024455de65e3d00de6f17 Mon Sep 17 00:00:00 2001
From: Zi Yan <ziy@nvidia.com>
Date: Tue, 4 Aug 2026 17:04:27 -0400
Subject: [PATCH] mm/huge_memory: use folio's memcg inside __folio_split()

Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to
folio's memcg", v3.

__GFP_ACCOUNT is needed for xarray node allocation accounting when
XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
convergence regression") fixed a workingset regression with it.
xas_split_alloc() does not have it and needs to be fixed.

In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to
charge the right memcg, folio's memcg needs to be active during folio
split. Add that before adding __GFP_ACCOUNT.

There is no workingset convergence regression related to missing
__GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be
minor.


This patch (of 2):

During a pagecache folio split, an xarray node allocation can happen and
needs to charge at folio's memcg instead of folio split invoker's memcg,
because for example folio split can happen during reclaim and reclaim's
active memcg might not be folio's memcg.  Switch to folio's memcg at the
beginning and switch back afterwards.

Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com
Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com
Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1]
Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2]
Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
Signed-off-by: Zi Yan <ziy@nvidia.com>
Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Barry Song <baohua@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a8174d1d3848..ced400f72d43 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -4105,34 +4105,42 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 	XA_STATE(xas, &folio->mapping->i_pages, folio->index);
 	struct folio *end_folio = folio_next(folio);
 	bool is_anon = folio_test_anon(folio);
+	struct mem_cgroup *memcg, *old_memcg;
 	struct address_space *mapping = NULL;
 	struct anon_vma *anon_vma = NULL;
 	int old_order = folio_order(folio);
 	struct folio *new_folio, *next;
 	int nr_shmem_dropped = 0;
 	enum ttu_flags ttu_flags = 0;
-	int ret;
 	pgoff_t end = 0;
+	int ret;
 
 	VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio);
 	VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
 
 	if (folio != page_folio(split_at) || folio != page_folio(lock_at)) {
 		ret = -EINVAL;
-		goto out;
+		goto out_no_memcg;
 	}
 
 	if (new_order >= old_order) {
 		ret = -EINVAL;
-		goto out;
+		goto out_no_memcg;
 	}
 
 	ret = folio_check_splittable(folio, new_order, split_type);
 	if (ret) {
 		VM_WARN_ONCE(ret == -EINVAL, "Tried to split an unsplittable folio");
-		goto out;
+		goto out_no_memcg;
 	}
 
+	/*
+	 * switch to folio's memcg as xarray node allocation can happen and
+	 * needs to charge to it.
+	 */
+	memcg = get_mem_cgroup_from_folio(folio);
+	old_memcg = set_active_memcg(memcg);
+
 	if (is_anon) {
 		/*
 		 * The caller does not necessarily hold an mmap_lock that would
@@ -4275,6 +4283,10 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 	if (mapping)
 		i_mmap_unlock_read(mapping);
 out:
+	/* restore to caller's old_memcg */
+	set_active_memcg(old_memcg);
+	mem_cgroup_put(memcg);
+out_no_memcg:
 	xas_destroy(&xas);
 	if (is_pmd_order(old_order))
 		count_vm_event(!ret ? THP_SPLIT_PAGE : THP_SPLIT_PAGE_FAILED);

[PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Zi Yan]

Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to
folio's memcg", v3.

__GFP_ACCOUNT is needed for xarray node allocation accounting when
XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
convergence regression") fixed a workingset regression with it.
xas_split_alloc() does not have it and needs to be fixed.

In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to
charge the right memcg, folio's memcg needs to be active during folio
split. Add that before adding __GFP_ACCOUNT.

There is no workingset convergence regression related to missing
__GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be
minor.

This patch (of 2):

During a pagecache folio split, an xarray node allocation can happen and
needs to charge at folio's memcg instead of folio split invoker's memcg,
because for example folio split can happen during reclaim and reclaim's
active memcg might not be folio's memcg.  Switch to folio's memcg at the
beginning and switch back afterwards.

Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com
Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com
Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1]
Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2]
Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
Signed-off-by: Zi Yan <ziy@nvidia.com>
Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Barry Song <baohua@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit c299a2285d9d8bda4da024455de65e3d00de6f17)
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 mm/huge_memory.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7ab6779849243..8df057bbe1bca 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2646,6 +2646,7 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	struct folio *folio = page_folio(page);
 	struct deferred_split *ds_queue = get_deferred_split_queue(folio);
 	XA_STATE(xas, &folio->mapping->i_pages, folio->index);
+	struct mem_cgroup *memcg, *old_memcg;
 	struct anon_vma *anon_vma = NULL;
 	struct address_space *mapping = NULL;
 	int extra_pins, ret;
@@ -2664,6 +2665,13 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	if (folio_test_writeback(folio))
 		return -EBUSY;
 
+	/*
+	 * switch to folio's memcg as xarray node allocation can happen and
+	 * needs to charge to it.
+	 */
+	memcg = folio_memcg(folio);
+	old_memcg = set_active_memcg(memcg);
+
 	if (folio_test_anon(folio)) {
 		/*
 		 * The caller does not necessarily hold an mmap_lock that would
@@ -2792,6 +2800,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	if (mapping)
 		i_mmap_unlock_read(mapping);
 out:
+	/* restore to caller's old_memcg */
+	set_active_memcg(old_memcg);
 	xas_destroy(&xas);
 	count_vm_event(!ret ? THP_SPLIT_PAGE : THP_SPLIT_PAGE_FAILED);
 	return ret;
-- 
2.53.0

[PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Sasha Levin]

From: Zi Yan <ziy@nvidia.com>

[ Upstream commit c299a2285d9d8bda4da024455de65e3d00de6f17 ]

Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to
folio's memcg", v3.

__GFP_ACCOUNT is needed for xarray node allocation accounting when
XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
convergence regression") fixed a workingset regression with it.
xas_split_alloc() does not have it and needs to be fixed.

In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to
charge the right memcg, folio's memcg needs to be active during folio
split. Add that before adding __GFP_ACCOUNT.

There is no workingset convergence regression related to missing
__GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be
minor.

This patch (of 2):

During a pagecache folio split, an xarray node allocation can happen and
needs to charge at folio's memcg instead of folio split invoker's memcg,
because for example folio split can happen during reclaim and reclaim's
active memcg might not be folio's memcg.  Switch to folio's memcg at the
beginning and switch back afterwards.

Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com
Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com
Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1]
Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2]
Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
Signed-off-by: Zi Yan <ziy@nvidia.com>
Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Barry Song <baohua@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ adapted get_mem_cgroup_from_folio() to the older folio_memcg()/css_tryget() sequence in split_huge_page_to_list() ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 mm/huge_memory.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7ab6779849243..8c626f7c1aedc 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2646,6 +2646,7 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	struct folio *folio = page_folio(page);
 	struct deferred_split *ds_queue = get_deferred_split_queue(folio);
 	XA_STATE(xas, &folio->mapping->i_pages, folio->index);
+	struct mem_cgroup *memcg, *old_memcg;
 	struct anon_vma *anon_vma = NULL;
 	struct address_space *mapping = NULL;
 	int extra_pins, ret;
@@ -2664,6 +2665,19 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	if (folio_test_writeback(folio))
 		return -EBUSY;
 
+	/*
+	 * switch to folio's memcg as xarray node allocation can happen and
+	 * needs to charge to it.
+	 */
+#ifdef CONFIG_MEMCG
+	memcg = folio_memcg(folio);
+	if (!memcg || WARN_ON_ONCE(!css_tryget(&memcg->css)))
+		memcg = root_mem_cgroup;
+#else
+	memcg = NULL;
+#endif
+	old_memcg = set_active_memcg(memcg);
+
 	if (folio_test_anon(folio)) {
 		/*
 		 * The caller does not necessarily hold an mmap_lock that would
@@ -2792,6 +2806,9 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	if (mapping)
 		i_mmap_unlock_read(mapping);
 out:
+	/* restore to caller's old_memcg */
+	set_active_memcg(old_memcg);
+	mem_cgroup_put(memcg);
 	xas_destroy(&xas);
 	count_vm_event(!ret ? THP_SPLIT_PAGE : THP_SPLIT_PAGE_FAILED);
 	return ret;
-- 
2.53.0

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Sasha Levin]

> __GFP_ACCOUNT is needed for xarray node allocation accounting when
> XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
> convergence regression") fixed a workingset regression with it.
> xas_split_alloc() does not have it and needs to be fixed.

Mainline's c299a2285d9d takes a reference on the folio's memcg with
get_mem_cgroup_from_folio() and holds it in current->active_memcg for the
duration of __folio_split() - rcu_read_lock()+css_tryget(), released with
mem_cgroup_put() afterwards. This 6.6.y version instead holds a bare
folio_memcg(folio) pointer across the same window, which includes a TLB
shootdown and several lock acquisitions - exactly the kind of window the
upstream refcount exists to close.

6.6 already has rcu_read_lock(), css_tryget() and mem_cgroup_put() available,
so nothing's missing to do this the same way upstream does.  Could you resend a
v2 that takes and drops the reference (under CONFIG_MEMCG, as upstream does)?

-- 
Thanks,
Sasha

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Zi Yan]

On Sun Sep 6, 2026 at 9:33 AM EDT, Sasha Levin wrote:
>> __GFP_ACCOUNT is needed for xarray node allocation accounting when
>> XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
>> convergence regression") fixed a workingset regression with it.
>> xas_split_alloc() does not have it and needs to be fixed.
>
> Mainline's c299a2285d9d takes a reference on the folio's memcg with
> get_mem_cgroup_from_folio() and holds it in current->active_memcg for the
> duration of __folio_split() - rcu_read_lock()+css_tryget(), released with
> mem_cgroup_put() afterwards. This 6.6.y version instead holds a bare
> folio_memcg(folio) pointer across the same window, which includes a TLB
> shootdown and several lock acquisitions - exactly the kind of window the
> upstream refcount exists to close.
>
> 6.6 already has rcu_read_lock(), css_tryget() and mem_cgroup_put() available,
> so nothing's missing to do this the same way upstream does.  Could you resend a
> v2 that takes and drops the reference (under CONFIG_MEMCG, as upstream does)?

No, this is not needed. Before commit f1cf8d2f36dc3 ("mm: memcontrol:
eliminate the problem of dying memory cgroup for LRU folios"), like
v6.6, a charged folio take a ref on its memcg. During split, the folio
is locked, so will not be uncharged. As a result, its memcg will not go
away.

According to Claude, adding a ref there might cause a deadlock when a
to-be-split folio has a dying memcg, where css_tryget() keeps failing
and folio_memcg() keeps returning the same memcg.

This should also apply to v6.1. I will send my version for 6.1 backport.


-- 
Best Regards,
Yan, Zi

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Sasha Levin]

> No, this is not needed. Before commit f1cf8d2f36dc3 ("mm: memcontrol:
> eliminate the problem of dying memory cgroup for LRU folios"), like
> v6.6, a charged folio take a ref on its memcg. During split, the folio
> is locked, so will not be uncharged. As a result, its memcg will not go
> away.

A review from one of the mm/ folks will be appreciated here :)

-- 
Thanks,
Sasha

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Johannes Weiner]

On Sun, Sep 06, 2026 at 06:46:55PM -0400, Zi Yan wrote:
> On Sun Sep 6, 2026 at 9:33 AM EDT, Sasha Levin wrote:
> >> __GFP_ACCOUNT is needed for xarray node allocation accounting when
> >> XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
> >> convergence regression") fixed a workingset regression with it.
> >> xas_split_alloc() does not have it and needs to be fixed.
> >
> > Mainline's c299a2285d9d takes a reference on the folio's memcg with
> > get_mem_cgroup_from_folio() and holds it in current->active_memcg for the
> > duration of __folio_split() - rcu_read_lock()+css_tryget(), released with
> > mem_cgroup_put() afterwards. This 6.6.y version instead holds a bare
> > folio_memcg(folio) pointer across the same window, which includes a TLB
> > shootdown and several lock acquisitions - exactly the kind of window the
> > upstream refcount exists to close.
> >
> > 6.6 already has rcu_read_lock(), css_tryget() and mem_cgroup_put() available,
> > so nothing's missing to do this the same way upstream does.  Could you resend a
> > v2 that takes and drops the reference (under CONFIG_MEMCG, as upstream does)?
> 
> No, this is not needed. Before commit f1cf8d2f36dc3 ("mm: memcontrol:
> eliminate the problem of dying memory cgroup for LRU folios"), like
> v6.6, a charged folio take a ref on its memcg. During split, the folio
> is locked, so will not be uncharged. As a result, its memcg will not go
> away.

Yes. It's safe until that last unlock & free in
__split_huge_page(). We don't have allocations or indirect references
to current->active_memcg afterwards that I can see.

> According to Claude, adding a ref there might cause a deadlock when a
> to-be-split folio has a dying memcg, where css_tryget() keeps failing
> and folio_memcg() keeps returning the same memcg.

If the cgroup was rmdir'd, only css_tryget_online() would fail. The
page itself holds a reference, keeping the dying cgroup from being
freed. And css_tryget() would still work.

So it would be doable if you wanted to keep the backport closer to
what we have upstream. But yes, it's not strictly necessary.

Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Sasha Levin]

Thanks for the review, Johannes.

I'm holding the 6.6.y patch for now, because 6.12.y needs this first.
c299a2285d9d ("mm/huge_memory: use folio's memcg inside
__folio_split()") is absent from 6.12.y, and we don't queue a fix on an
older tree while a newer one still lacks it.

6.12.y also needs its own version rather than this one. I tried your 6.6.y
patch against it and it fails at mm/huge_memory.c:2646. The two trees have
different shapes here: 6.6.y has split_huge_page_to_list(page, list) using
XA_STATE, while 6.12.y has split_huge_page_to_list_to_order(page, list,
new_order) using XA_STATE_ORDER.

Zi Yan, could you send a 6.12.y backport? Once that one is in I'll take
both together.

-- 
Thanks,
Sasha

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Zi Yan]

On Sat Sep 12, 2026 at 11:26 AM EDT, Sasha Levin wrote:
> Thanks for the review, Johannes.
>
> I'm holding the 6.6.y patch for now, because 6.12.y needs this first.
> c299a2285d9d ("mm/huge_memory: use folio's memcg inside
> __folio_split()") is absent from 6.12.y, and we don't queue a fix on an
> older tree while a newer one still lacks it.
>
> 6.12.y also needs its own version rather than this one. I tried your 6.6.y
> patch against it and it fails at mm/huge_memory.c:2646. The two trees have
> different shapes here: 6.6.y has split_huge_page_to_list(page, list) using
> XA_STATE, while 6.12.y has split_huge_page_to_list_to_order(page, list,
> new_order) using XA_STATE_ORDER.
>
> Zi Yan, could you send a 6.12.y backport? Once that one is in I'll take
> both together.

Done. See https://lore.kernel.org/all/20260912182926.1326147-1-ziy@nvidia.com/

BTW, I see you also sent one[1], but it seems that it is using a
non-existing get_mem_cgroup_from_folio(). What is that for? Thanks.

[1] https://lore.kernel.org/all/20260903223027.1739434-1-sashal@kernel.org/


-- 
Best Regards,
Yan, Zi

Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

[Sasha Levin]

> Done. See https://lore.kernel.org/all/20260912182926.1326147-1-ziy@nvidia.com/

Queued for 6.12 and 6.6, thanks.

> BTW, I see you also sent one[1], but it seems that it is using a
> non-existing get_mem_cgroup_from_folio(). What is that for? Thanks.

That one was generated against a tree that has the helper and should not
have gone out for 6.6.y. Please ignore it, yours is what is queued.

-- 
Thanks,
Sasha