FAILED: patch "[PATCH] mm: folio_may_be_lru_cached() unless folio_test_large()" failed to apply to 6.12-stable tree

FAILED: patch "[PATCH] mm: folio_may_be_lru_cached() unless folio_test_large()" failed to apply to 6.12-stable tree

[gregkh]

The patch below does not apply to the 6.12-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.12.y
git checkout FETCH_HEAD
git cherry-pick -x 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2025092142-easiness-blatancy-23af@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

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

From 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 Mon Sep 17 00:00:00 2001
From: Hugh Dickins <hughd@google.com>
Date: Mon, 8 Sep 2025 15:23:15 -0700
Subject: [PATCH] mm: folio_may_be_lru_cached() unless folio_test_large()

mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
large folio is added: so collect_longterm_unpinnable_folios() just wastes
effort when calling lru_add_drain[_all]() on a large folio.

But although there is good reason not to batch up PMD-sized folios, we
might well benefit from batching a small number of low-order mTHPs (though
unclear how that "small number" limitation will be implemented).

So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
insulate those particular checks from future change.  Name preferred to
"folio_is_batchable" because large folios can well be put on a batch: it's
just the per-CPU LRU caches, drained much later, which need care.

Marked for stable, to counter the increase in lru_add_drain_all()s from
"mm/gup: check ref_count instead of lru before migration".

Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
Signed-off-by: Hugh Dickins <hughd@google.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Keir Fraser <keirf@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Li Zhe <lizhe.67@bytedance.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Shivank Garg <shivankg@amd.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Xu <weixugc@google.com>
Cc: Will Deacon <will@kernel.org>
Cc: yangge <yangge1116@126.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 2fe6ed2cc3fd..7012a0f758d8 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -385,6 +385,16 @@ void folio_add_lru_vma(struct folio *, struct vm_area_struct *);
 void mark_page_accessed(struct page *);
 void folio_mark_accessed(struct folio *);
 
+static inline bool folio_may_be_lru_cached(struct folio *folio)
+{
+	/*
+	 * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting.
+	 * Holding small numbers of low-order mTHP folios in per-CPU LRU cache
+	 * will be sensible, but nobody has implemented and tested that yet.
+	 */
+	return !folio_test_large(folio);
+}
+
 extern atomic_t lru_disable_count;
 
 static inline bool lru_cache_disabled(void)
diff --git a/mm/gup.c b/mm/gup.c
index b47066a54f52..0bc4d140fc07 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2307,13 +2307,13 @@ static unsigned long collect_longterm_unpinnable_folios(
 			continue;
 		}
 
-		if (drained == 0 &&
+		if (drained == 0 && folio_may_be_lru_cached(folio) &&
 				folio_ref_count(folio) !=
 				folio_expected_ref_count(folio) + 1) {
 			lru_add_drain();
 			drained = 1;
 		}
-		if (drained == 1 &&
+		if (drained == 1 && folio_may_be_lru_cached(folio) &&
 				folio_ref_count(folio) !=
 				folio_expected_ref_count(folio) + 1) {
 			lru_add_drain_all();
diff --git a/mm/mlock.c b/mm/mlock.c
index a1d93ad33c6d..bb0776f5ef7c 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -255,7 +255,7 @@ void mlock_folio(struct folio *folio)
 
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, mlock_lru(folio)) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
@@ -278,7 +278,7 @@ void mlock_new_folio(struct folio *folio)
 
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, mlock_new(folio)) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
@@ -299,7 +299,7 @@ void munlock_folio(struct folio *folio)
 	 */
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, folio) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
diff --git a/mm/swap.c b/mm/swap.c
index 6ae2d5680574..b74ebe865dd9 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -192,7 +192,7 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
 		local_lock(&cpu_fbatches.lock);
 
 	if (!folio_batch_add(this_cpu_ptr(fbatch), folio) ||
-			folio_test_large(folio) || lru_cache_disabled())
+			!folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
 
 	if (disable_irq)

[PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Sasha Levin]

From: Hugh Dickins <hughd@google.com>

[ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]

mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
large folio is added: so collect_longterm_unpinnable_folios() just wastes
effort when calling lru_add_drain[_all]() on a large folio.

But although there is good reason not to batch up PMD-sized folios, we
might well benefit from batching a small number of low-order mTHPs (though
unclear how that "small number" limitation will be implemented).

So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
insulate those particular checks from future change.  Name preferred to
"folio_is_batchable" because large folios can well be put on a batch: it's
just the per-CPU LRU caches, drained much later, which need care.

Marked for stable, to counter the increase in lru_add_drain_all()s from
"mm/gup: check ref_count instead of lru before migration".

Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
Signed-off-by: Hugh Dickins <hughd@google.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Keir Fraser <keirf@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Li Zhe <lizhe.67@bytedance.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Shivank Garg <shivankg@amd.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Xu <weixugc@google.com>
Cc: Will Deacon <will@kernel.org>
Cc: yangge <yangge1116@126.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ adapted to drain_allow instead of drained ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/linux/swap.h | 10 ++++++++++
 mm/gup.c             |  3 ++-
 mm/mlock.c           |  6 +++---
 mm/swap.c            |  4 ++--
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index f3e0ac20c2e8c..63f85b3fee238 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -382,6 +382,16 @@ void folio_add_lru_vma(struct folio *, struct vm_area_struct *);
 void mark_page_accessed(struct page *);
 void folio_mark_accessed(struct folio *);
 
+static inline bool folio_may_be_lru_cached(struct folio *folio)
+{
+	/*
+	 * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting.
+	 * Holding small numbers of low-order mTHP folios in per-CPU LRU cache
+	 * will be sensible, but nobody has implemented and tested that yet.
+	 */
+	return !folio_test_large(folio);
+}
+
 extern atomic_t lru_disable_count;
 
 static inline bool lru_cache_disabled(void)
diff --git a/mm/gup.c b/mm/gup.c
index e323843cc5dd8..a919ee0f5b778 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2354,7 +2354,8 @@ static unsigned long collect_longterm_unpinnable_folios(
 			continue;
 		}
 
-		if (!folio_test_lru(folio) && drain_allow) {
+		if (!folio_test_lru(folio) && folio_may_be_lru_cached(folio) &&
+		    drain_allow) {
 			lru_add_drain_all();
 			drain_allow = false;
 		}
diff --git a/mm/mlock.c b/mm/mlock.c
index cde076fa7d5e5..8c8d522efdd59 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -255,7 +255,7 @@ void mlock_folio(struct folio *folio)
 
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, mlock_lru(folio)) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
@@ -278,7 +278,7 @@ void mlock_new_folio(struct folio *folio)
 
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, mlock_new(folio)) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
@@ -299,7 +299,7 @@ void munlock_folio(struct folio *folio)
 	 */
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, folio) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
diff --git a/mm/swap.c b/mm/swap.c
index 59f30a981c6f9..e8536e3b48149 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -222,8 +222,8 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
 	else
 		local_lock(&cpu_fbatches.lock);
 
-	if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || folio_test_large(folio) ||
-	    lru_cache_disabled())
+	if (!folio_batch_add(this_cpu_ptr(fbatch), folio) ||
+			!folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
 
 	if (disable_irq)
-- 
2.51.0

Re: [PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Greg KH]

On Sun, Sep 21, 2025 at 11:41:34AM -0400, Sasha Levin wrote:
> From: Hugh Dickins <hughd@google.com>
> 
> [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
> 
> mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
> large folio is added: so collect_longterm_unpinnable_folios() just wastes
> effort when calling lru_add_drain[_all]() on a large folio.
> 
> But although there is good reason not to batch up PMD-sized folios, we
> might well benefit from batching a small number of low-order mTHPs (though
> unclear how that "small number" limitation will be implemented).
> 
> So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
> insulate those particular checks from future change.  Name preferred to
> "folio_is_batchable" because large folios can well be put on a batch: it's
> just the per-CPU LRU caches, drained much later, which need care.
> 
> Marked for stable, to counter the increase in lru_add_drain_all()s from
> "mm/gup: check ref_count instead of lru before migration".
> 
> Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
> Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
> Signed-off-by: Hugh Dickins <hughd@google.com>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Axel Rasmussen <axelrasmussen@google.com>
> Cc: Chris Li <chrisl@kernel.org>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Keir Fraser <keirf@google.com>
> Cc: Konstantin Khlebnikov <koct9i@gmail.com>
> Cc: Li Zhe <lizhe.67@bytedance.com>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Shivank Garg <shivankg@amd.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Wei Xu <weixugc@google.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: yangge <yangge1116@126.com>
> Cc: Yuanchu Xie <yuanchu@google.com>
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> [ adapted to drain_allow instead of drained ]
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---

Does not apply as it conflicts with the other mm changes you sent right
before this one :(

Re: [PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Hugh Dickins]

On Sun, 21 Sep 2025, Greg KH wrote:
> On Sun, Sep 21, 2025 at 11:41:34AM -0400, Sasha Levin wrote:
> > From: Hugh Dickins <hughd@google.com>
> > 
> > [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
> > 
> > mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
> > large folio is added: so collect_longterm_unpinnable_folios() just wastes
> > effort when calling lru_add_drain[_all]() on a large folio.
> > 
> > But although there is good reason not to batch up PMD-sized folios, we
> > might well benefit from batching a small number of low-order mTHPs (though
> > unclear how that "small number" limitation will be implemented).
> > 
> > So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
> > insulate those particular checks from future change.  Name preferred to
> > "folio_is_batchable" because large folios can well be put on a batch: it's
> > just the per-CPU LRU caches, drained much later, which need care.
> > 
> > Marked for stable, to counter the increase in lru_add_drain_all()s from
> > "mm/gup: check ref_count instead of lru before migration".
> > 
> > Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
> > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
> > Signed-off-by: Hugh Dickins <hughd@google.com>
> > Suggested-by: David Hildenbrand <david@redhat.com>
> > Acked-by: David Hildenbrand <david@redhat.com>
> > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> > Cc: Axel Rasmussen <axelrasmussen@google.com>
> > Cc: Chris Li <chrisl@kernel.org>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: John Hubbard <jhubbard@nvidia.com>
> > Cc: Keir Fraser <keirf@google.com>
> > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
> > Cc: Li Zhe <lizhe.67@bytedance.com>
> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> > Cc: Peter Xu <peterx@redhat.com>
> > Cc: Rik van Riel <riel@surriel.com>
> > Cc: Shivank Garg <shivankg@amd.com>
> > Cc: Vlastimil Babka <vbabka@suse.cz>
> > Cc: Wei Xu <weixugc@google.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: yangge <yangge1116@126.com>
> > Cc: Yuanchu Xie <yuanchu@google.com>
> > Cc: Yu Zhao <yuzhao@google.com>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > [ adapted to drain_allow instead of drained ]
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> 
> Does not apply as it conflicts with the other mm changes you sent right
> before this one :(

Thanks for grabbing all these, I'm sorry they are troublesome.

Though I'm usually able to work out what to do from the FAILED mails,
in this case I'd just be guessing without the full contexts.
So I'll wait until I see what goes into the various branches of
linux-stable-rc.git before checking and adjusting where necessary.

(As usual, I'll tend towards minimal change, where Sasha tends
towards maximal backporting of encroaching mods: we may disagree.)

The main commits contributing to the pinning failures that Will Deacon
reported were commits going into 5.18 and 6.11.  So although I stand
by my Fixes tag, I'm likely to conclude that 5.15 and 5.10 and 5.4
are better left stable without any of it.

Thanks,
Hugh

Re: [PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Will Deacon]

On Sun, Sep 21, 2025 at 09:05:35PM -0700, Hugh Dickins wrote:
> On Sun, 21 Sep 2025, Greg KH wrote:
> > On Sun, Sep 21, 2025 at 11:41:34AM -0400, Sasha Levin wrote:
> > > From: Hugh Dickins <hughd@google.com>
> > > 
> > > [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
> > > 
> > > mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
> > > large folio is added: so collect_longterm_unpinnable_folios() just wastes
> > > effort when calling lru_add_drain[_all]() on a large folio.
> > > 
> > > But although there is good reason not to batch up PMD-sized folios, we
> > > might well benefit from batching a small number of low-order mTHPs (though
> > > unclear how that "small number" limitation will be implemented).
> > > 
> > > So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
> > > insulate those particular checks from future change.  Name preferred to
> > > "folio_is_batchable" because large folios can well be put on a batch: it's
> > > just the per-CPU LRU caches, drained much later, which need care.
> > > 
> > > Marked for stable, to counter the increase in lru_add_drain_all()s from
> > > "mm/gup: check ref_count instead of lru before migration".
> > > 
> > > Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
> > > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
> > > Signed-off-by: Hugh Dickins <hughd@google.com>
> > > Suggested-by: David Hildenbrand <david@redhat.com>
> > > Acked-by: David Hildenbrand <david@redhat.com>
> > > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> > > Cc: Axel Rasmussen <axelrasmussen@google.com>
> > > Cc: Chris Li <chrisl@kernel.org>
> > > Cc: Christoph Hellwig <hch@infradead.org>
> > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> > > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > > Cc: John Hubbard <jhubbard@nvidia.com>
> > > Cc: Keir Fraser <keirf@google.com>
> > > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
> > > Cc: Li Zhe <lizhe.67@bytedance.com>
> > > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > Cc: Peter Xu <peterx@redhat.com>
> > > Cc: Rik van Riel <riel@surriel.com>
> > > Cc: Shivank Garg <shivankg@amd.com>
> > > Cc: Vlastimil Babka <vbabka@suse.cz>
> > > Cc: Wei Xu <weixugc@google.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: yangge <yangge1116@126.com>
> > > Cc: Yuanchu Xie <yuanchu@google.com>
> > > Cc: Yu Zhao <yuzhao@google.com>
> > > Cc: <stable@vger.kernel.org>
> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > > [ adapted to drain_allow instead of drained ]
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > ---
> > 
> > Does not apply as it conflicts with the other mm changes you sent right
> > before this one :(
> 
> Thanks for grabbing all these, I'm sorry they are troublesome.
> 
> Though I'm usually able to work out what to do from the FAILED mails,
> in this case I'd just be guessing without the full contexts.
> So I'll wait until I see what goes into the various branches of
> linux-stable-rc.git before checking and adjusting where necessary.
> 
> (As usual, I'll tend towards minimal change, where Sasha tends
> towards maximal backporting of encroaching mods: we may disagree.)
> 
> The main commits contributing to the pinning failures that Will Deacon
> reported were commits going into 5.18 and 6.11.  So although I stand
> by my Fixes tag, I'm likely to conclude that 5.15 and 5.10 and 5.4
> are better left stable without any of it.

That suits me. 6.1, 6.6 and 6.12 are the main ones that I'm concerned
with from the Android side.

Will

Re: [PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Sasha Levin]

On Mon, Sep 22, 2025 at 10:49:31AM +0100, Will Deacon wrote:
>On Sun, Sep 21, 2025 at 09:05:35PM -0700, Hugh Dickins wrote:
>> On Sun, 21 Sep 2025, Greg KH wrote:
>> > On Sun, Sep 21, 2025 at 11:41:34AM -0400, Sasha Levin wrote:
>> > > From: Hugh Dickins <hughd@google.com>
>> > >
>> > > [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
>> > >
>> > > mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
>> > > large folio is added: so collect_longterm_unpinnable_folios() just wastes
>> > > effort when calling lru_add_drain[_all]() on a large folio.
>> > >
>> > > But although there is good reason not to batch up PMD-sized folios, we
>> > > might well benefit from batching a small number of low-order mTHPs (though
>> > > unclear how that "small number" limitation will be implemented).
>> > >
>> > > So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
>> > > insulate those particular checks from future change.  Name preferred to
>> > > "folio_is_batchable" because large folios can well be put on a batch: it's
>> > > just the per-CPU LRU caches, drained much later, which need care.
>> > >
>> > > Marked for stable, to counter the increase in lru_add_drain_all()s from
>> > > "mm/gup: check ref_count instead of lru before migration".
>> > >
>> > > Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
>> > > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
>> > > Signed-off-by: Hugh Dickins <hughd@google.com>
>> > > Suggested-by: David Hildenbrand <david@redhat.com>
>> > > Acked-by: David Hildenbrand <david@redhat.com>
>> > > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
>> > > Cc: Axel Rasmussen <axelrasmussen@google.com>
>> > > Cc: Chris Li <chrisl@kernel.org>
>> > > Cc: Christoph Hellwig <hch@infradead.org>
>> > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
>> > > Cc: Johannes Weiner <hannes@cmpxchg.org>
>> > > Cc: John Hubbard <jhubbard@nvidia.com>
>> > > Cc: Keir Fraser <keirf@google.com>
>> > > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
>> > > Cc: Li Zhe <lizhe.67@bytedance.com>
>> > > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
>> > > Cc: Peter Xu <peterx@redhat.com>
>> > > Cc: Rik van Riel <riel@surriel.com>
>> > > Cc: Shivank Garg <shivankg@amd.com>
>> > > Cc: Vlastimil Babka <vbabka@suse.cz>
>> > > Cc: Wei Xu <weixugc@google.com>
>> > > Cc: Will Deacon <will@kernel.org>
>> > > Cc: yangge <yangge1116@126.com>
>> > > Cc: Yuanchu Xie <yuanchu@google.com>
>> > > Cc: Yu Zhao <yuzhao@google.com>
>> > > Cc: <stable@vger.kernel.org>
>> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> > > [ adapted to drain_allow instead of drained ]
>> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
>> > > ---
>> >
>> > Does not apply as it conflicts with the other mm changes you sent right
>> > before this one :(
>>
>> Thanks for grabbing all these, I'm sorry they are troublesome.
>>
>> Though I'm usually able to work out what to do from the FAILED mails,
>> in this case I'd just be guessing without the full contexts.
>> So I'll wait until I see what goes into the various branches of
>> linux-stable-rc.git before checking and adjusting where necessary.
>>
>> (As usual, I'll tend towards minimal change, where Sasha tends
>> towards maximal backporting of encroaching mods: we may disagree.)
>>
>> The main commits contributing to the pinning failures that Will Deacon
>> reported were commits going into 5.18 and 6.11.  So although I stand
>> by my Fixes tag, I'm likely to conclude that 5.15 and 5.10 and 5.4
>> are better left stable without any of it.
>
>That suits me. 6.1, 6.6 and 6.12 are the main ones that I'm concerned
>with from the Android side.

I'll hold off on backports then :)

-- 
Thanks,
Sasha

Re: [PATCH 6.12.y] mm: folio_may_be_lru_cached() unless folio_test_large()

[Hugh Dickins]

[-- Attachment #1: Type: text/plain, Size: 5165 bytes --]

On Mon, 22 Sep 2025, Sasha Levin wrote:
> On Mon, Sep 22, 2025 at 10:49:31AM +0100, Will Deacon wrote:
> >On Sun, Sep 21, 2025 at 09:05:35PM -0700, Hugh Dickins wrote:
> >> On Sun, 21 Sep 2025, Greg KH wrote:
> >> > On Sun, Sep 21, 2025 at 11:41:34AM -0400, Sasha Levin wrote:
> >> > > From: Hugh Dickins <hughd@google.com>
> >> > >
> >> > > [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
> >> > >
> >> > > mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
> >> > > large folio is added: so collect_longterm_unpinnable_folios() just
> >> > > wastes
> >> > > effort when calling lru_add_drain[_all]() on a large folio.
> >> > >
> >> > > But although there is good reason not to batch up PMD-sized folios, we
> >> > > might well benefit from batching a small number of low-order mTHPs
> >> > > (though
> >> > > unclear how that "small number" limitation will be implemented).
> >> > >
> >> > > So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
> >> > > insulate those particular checks from future change.  Name preferred to
> >> > > "folio_is_batchable" because large folios can well be put on a batch:
> >> > > it's
> >> > > just the per-CPU LRU caches, drained much later, which need care.
> >> > >
> >> > > Marked for stable, to counter the increase in lru_add_drain_all()s from
> >> > > "mm/gup: check ref_count instead of lru before migration".
> >> > >
> >> > > Link:
> >> > > https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
> >> > > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate
> >> > > pages allocated from CMA region")
> >> > > Signed-off-by: Hugh Dickins <hughd@google.com>
> >> > > Suggested-by: David Hildenbrand <david@redhat.com>
> >> > > Acked-by: David Hildenbrand <david@redhat.com>
> >> > > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> >> > > Cc: Axel Rasmussen <axelrasmussen@google.com>
> >> > > Cc: Chris Li <chrisl@kernel.org>
> >> > > Cc: Christoph Hellwig <hch@infradead.org>
> >> > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> >> > > Cc: Johannes Weiner <hannes@cmpxchg.org>
> >> > > Cc: John Hubbard <jhubbard@nvidia.com>
> >> > > Cc: Keir Fraser <keirf@google.com>
> >> > > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
> >> > > Cc: Li Zhe <lizhe.67@bytedance.com>
> >> > > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> >> > > Cc: Peter Xu <peterx@redhat.com>
> >> > > Cc: Rik van Riel <riel@surriel.com>
> >> > > Cc: Shivank Garg <shivankg@amd.com>
> >> > > Cc: Vlastimil Babka <vbabka@suse.cz>
> >> > > Cc: Wei Xu <weixugc@google.com>
> >> > > Cc: Will Deacon <will@kernel.org>
> >> > > Cc: yangge <yangge1116@126.com>
> >> > > Cc: Yuanchu Xie <yuanchu@google.com>
> >> > > Cc: Yu Zhao <yuzhao@google.com>
> >> > > Cc: <stable@vger.kernel.org>
> >> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >> > > [ adapted to drain_allow instead of drained ]
> >> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> >> > > ---
> >> >
> >> > Does not apply as it conflicts with the other mm changes you sent right
> >> > before this one :(
> >>
> >> Thanks for grabbing all these, I'm sorry they are troublesome.
> >>
> >> Though I'm usually able to work out what to do from the FAILED mails,
> >> in this case I'd just be guessing without the full contexts.
> >> So I'll wait until I see what goes into the various branches of
> >> linux-stable-rc.git before checking and adjusting where necessary.
> >>
> >> (As usual, I'll tend towards minimal change, where Sasha tends
> >> towards maximal backporting of encroaching mods: we may disagree.)
> >>
> >> The main commits contributing to the pinning failures that Will Deacon
> >> reported were commits going into 5.18 and 6.11.  So although I stand
> >> by my Fixes tag, I'm likely to conclude that 5.15 and 5.10 and 5.4
> >> are better left stable without any of it.
> >
> >That suits me. 6.1, 6.6 and 6.12 are the main ones that I'm concerned
> >with from the Android side.
> 
> I'll hold off on backports then :)

Sure :)

I'm fading: let me explain and send what I have so far.

6.16.9-rc1 is fine, no further change needed from me, thanks.

6.12.49-rc1 is okay with what's in it already,
but needs the missing three patches on top, attached.

0001*patch and 0003*patch are actually just clean cherry-picks, I expect
the 0001*patch FAILED originally because of needing a Stable-dep, which
later did get into the rc1 tree.  If you prefer, feel free to ignore
my attached 0001*patch and 0003*patch (with my additional Signoffs),
cherry-pick for yourself, and just apply my 0002*patch between them.

6.6.108-rc1 (not yet posted, but there in linux-stable-rc.git):
sensibly does not yet contain any of the lrudrain series, I'm assembling
them, but just hit a snag - I've noticed that the 6.6-stable mm/gup.c
collect_longterm_unpinnable_pages(), which I'm patching, contains a mod
which was later reverted in Linus's tree, the revert was marked for stable
but I expect it ended up as FAILED, so I need to spend more time looking
into that (6.14 1aaf8c122918 reverted by 6.16 517f496e1e61): not tonight.

After I've settled 6.6, I'll move on to 6.1, but no further.

Hugh

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch; name=0001-mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_al.patch, Size: 3065 bytes --]

From 7affc63035963917e25a798a8c22065cd06dcefb Mon Sep 17 00:00:00 2001
From: Hugh Dickins <hughd@google.com>
Date: Mon, 8 Sep 2025 15:16:53 -0700
Subject: [PATCH 1/3] mm/gup: local lru_add_drain() to avoid
 lru_add_drain_all()

[ Upstream commit a09a8a1fbb374e0053b97306da9dbc05bd384685 ]

In many cases, if collect_longterm_unpinnable_folios() does need to drain
the LRU cache to release a reference, the cache in question is on this
same CPU, and much more efficiently drained by a preliminary local
lru_add_drain(), than the later cross-CPU lru_add_drain_all().

Marked for stable, to counter the increase in lru_add_drain_all()s from
"mm/gup: check ref_count instead of lru before migration".  Note for clean
backports: can take 6.16 commit a03db236aebf ("gup: optimize longterm
pin_user_pages() for large folio") first.

Link: https://lkml.kernel.org/r/66f2751f-283e-816d-9530-765db7edc465@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Keir Fraser <keirf@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Li Zhe <lizhe.67@bytedance.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Shivank Garg <shivankg@amd.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Xu <weixugc@google.com>
Cc: Will Deacon <will@kernel.org>
Cc: yangge <yangge1116@126.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ Clean cherry-pick now into this tree ]
Signed-off-by: Hugh Dickins <hughd@google.com>
---
 mm/gup.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index e9be7c49542a..4dd0eb70988b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2356,8 +2356,8 @@ static unsigned long collect_longterm_unpinnable_folios(
 		struct pages_or_folios *pofs)
 {
 	unsigned long collected = 0;
-	bool drain_allow = true;
 	struct folio *folio;
+	int drained = 0;
 	long i = 0;
 
 	for (folio = pofs_get_folio(pofs, i); folio;
@@ -2376,10 +2376,17 @@ static unsigned long collect_longterm_unpinnable_folios(
 			continue;
 		}
 
-		if (drain_allow && folio_ref_count(folio) !=
-				   folio_expected_ref_count(folio) + 1) {
+		if (drained == 0 &&
+				folio_ref_count(folio) !=
+				folio_expected_ref_count(folio) + 1) {
+			lru_add_drain();
+			drained = 1;
+		}
+		if (drained == 1 &&
+				folio_ref_count(folio) !=
+				folio_expected_ref_count(folio) + 1) {
 			lru_add_drain_all();
-			drain_allow = false;
+			drained = 2;
 		}
 
 		if (!folio_isolate_lru(folio))
-- 
2.51.0.534.gc79095c0ca-goog


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: text/x-patch; name=0002-mm-revert-mm-gup-clear-the-LRU-flag-of-a-page-before.patch, Size: 7443 bytes --]

From 39531c7ef37d9279da2cbdc6b9d7ba73824a8e6b Mon Sep 17 00:00:00 2001
From: Hugh Dickins <hughd@google.com>
Date: Mon, 8 Sep 2025 15:19:17 -0700
Subject: [PATCH 2/3] mm: revert "mm/gup: clear the LRU flag of a page before
 adding to LRU batch"

[ Upstream commit afb99e9f500485160f34b8cad6d3763ada3e80e8 ]

This reverts commit 33dfe9204f29: now that
collect_longterm_unpinnable_folios() is checking ref_count instead of lru,
and mlock/munlock do not participate in the revised LRU flag clearing,
those changes are misleading, and enlarge the window during which
mlock/munlock may miss an mlock_count update.

It is possible (I'd hesitate to claim probable) that the greater
likelihood of missed mlock_count updates would explain the "Realtime
threads delayed due to kcompactd0" observed on 6.12 in the Link below.  If
that is the case, this reversion will help; but a complete solution needs
also a further patch, beyond the scope of this series.

Included some 80-column cleanup around folio_batch_add_and_move().

The role of folio_test_clear_lru() (before taking per-memcg lru_lock) is
questionable since 6.13 removed mem_cgroup_move_account() etc; but perhaps
there are still some races which need it - not examined here.

Link: https://lore.kernel.org/linux-mm/DU0PR01MB10385345F7153F334100981888259A@DU0PR01MB10385.eurprd01.prod.exchangelabs.com/
Link: https://lkml.kernel.org/r/05905d7b-ed14-68b1-79d8-bdec30367eba@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Keir Fraser <keirf@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Li Zhe <lizhe.67@bytedance.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Shivank Garg <shivankg@amd.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Xu <weixugc@google.com>
Cc: Will Deacon <will@kernel.org>
Cc: yangge <yangge1116@126.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ Resolved conflicts in applying the revert to this tree ]
Signed-off-by: Hugh Dickins <hughd@google.com>
---
 mm/swap.c | 51 +++++++++++++++++++++++++++------------------------
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/mm/swap.c b/mm/swap.c
index 59f30a981c6f..d4cb4898f573 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -195,6 +195,10 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn)
 	for (i = 0; i < folio_batch_count(fbatch); i++) {
 		struct folio *folio = fbatch->folios[i];
 
+		/* block memcg migration while the folio moves between lru */
+		if (move_fn != lru_add && !folio_test_clear_lru(folio))
+			continue;
+
 		folio_lruvec_relock_irqsave(folio, &lruvec, &flags);
 		move_fn(lruvec, folio);
 
@@ -207,14 +211,10 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn)
 }
 
 static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
-		struct folio *folio, move_fn_t move_fn,
-		bool on_lru, bool disable_irq)
+		struct folio *folio, move_fn_t move_fn, bool disable_irq)
 {
 	unsigned long flags;
 
-	if (on_lru && !folio_test_clear_lru(folio))
-		return;
-
 	folio_get(folio);
 
 	if (disable_irq)
@@ -222,8 +222,8 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
 	else
 		local_lock(&cpu_fbatches.lock);
 
-	if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || folio_test_large(folio) ||
-	    lru_cache_disabled())
+	if (!folio_batch_add(this_cpu_ptr(fbatch), folio) ||
+			folio_test_large(folio) || lru_cache_disabled())
 		folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
 
 	if (disable_irq)
@@ -232,13 +232,13 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
 		local_unlock(&cpu_fbatches.lock);
 }
 
-#define folio_batch_add_and_move(folio, op, on_lru)						\
-	__folio_batch_add_and_move(								\
-		&cpu_fbatches.op,								\
-		folio,										\
-		op,										\
-		on_lru,										\
-		offsetof(struct cpu_fbatches, op) >= offsetof(struct cpu_fbatches, lock_irq)	\
+#define folio_batch_add_and_move(folio, op)		\
+	__folio_batch_add_and_move(			\
+		&cpu_fbatches.op,			\
+		folio,					\
+		op,					\
+		offsetof(struct cpu_fbatches, op) >=	\
+		offsetof(struct cpu_fbatches, lock_irq)	\
 	)
 
 static void lru_move_tail(struct lruvec *lruvec, struct folio *folio)
@@ -262,10 +262,10 @@ static void lru_move_tail(struct lruvec *lruvec, struct folio *folio)
 void folio_rotate_reclaimable(struct folio *folio)
 {
 	if (folio_test_locked(folio) || folio_test_dirty(folio) ||
-	    folio_test_unevictable(folio))
+	    folio_test_unevictable(folio) || !folio_test_lru(folio))
 		return;
 
-	folio_batch_add_and_move(folio, lru_move_tail, true);
+	folio_batch_add_and_move(folio, lru_move_tail);
 }
 
 void lru_note_cost(struct lruvec *lruvec, bool file,
@@ -354,10 +354,11 @@ static void folio_activate_drain(int cpu)
 
 void folio_activate(struct folio *folio)
 {
-	if (folio_test_active(folio) || folio_test_unevictable(folio))
+	if (folio_test_active(folio) || folio_test_unevictable(folio) ||
+	    !folio_test_lru(folio))
 		return;
 
-	folio_batch_add_and_move(folio, lru_activate, true);
+	folio_batch_add_and_move(folio, lru_activate);
 }
 
 #else
@@ -510,7 +511,7 @@ void folio_add_lru(struct folio *folio)
 	    lru_gen_in_fault() && !(current->flags & PF_MEMALLOC))
 		folio_set_active(folio);
 
-	folio_batch_add_and_move(folio, lru_add, false);
+	folio_batch_add_and_move(folio, lru_add);
 }
 EXPORT_SYMBOL(folio_add_lru);
 
@@ -685,10 +686,10 @@ void lru_add_drain_cpu(int cpu)
 void deactivate_file_folio(struct folio *folio)
 {
 	/* Deactivating an unevictable folio will not accelerate reclaim */
-	if (folio_test_unevictable(folio))
+	if (folio_test_unevictable(folio) || !folio_test_lru(folio))
 		return;
 
-	folio_batch_add_and_move(folio, lru_deactivate_file, true);
+	folio_batch_add_and_move(folio, lru_deactivate_file);
 }
 
 /*
@@ -701,10 +702,11 @@ void deactivate_file_folio(struct folio *folio)
  */
 void folio_deactivate(struct folio *folio)
 {
-	if (folio_test_unevictable(folio) || !(folio_test_active(folio) || lru_gen_enabled()))
+	if (folio_test_unevictable(folio) || !folio_test_lru(folio) ||
+	    !(folio_test_active(folio) || lru_gen_enabled()))
 		return;
 
-	folio_batch_add_and_move(folio, lru_deactivate, true);
+	folio_batch_add_and_move(folio, lru_deactivate);
 }
 
 /**
@@ -717,10 +719,11 @@ void folio_deactivate(struct folio *folio)
 void folio_mark_lazyfree(struct folio *folio)
 {
 	if (!folio_test_anon(folio) || !folio_test_swapbacked(folio) ||
+	    !folio_test_lru(folio) ||
 	    folio_test_swapcache(folio) || folio_test_unevictable(folio))
 		return;
 
-	folio_batch_add_and_move(folio, lru_lazyfree, true);
+	folio_batch_add_and_move(folio, lru_lazyfree);
 }
 
 void lru_add_drain(void)
-- 
2.51.0.534.gc79095c0ca-goog


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: text/x-patch; name=0003-mm-folio_may_be_lru_cached-unless-folio_test_large.patch, Size: 5632 bytes --]

From 7450544bc820b0c884a10e2348b8514166dab5cb Mon Sep 17 00:00:00 2001
From: Hugh Dickins <hughd@google.com>
Date: Mon, 8 Sep 2025 15:23:15 -0700
Subject: [PATCH 3/3] mm: folio_may_be_lru_cached() unless folio_test_large()

[ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]

mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
large folio is added: so collect_longterm_unpinnable_folios() just wastes
effort when calling lru_add_drain[_all]() on a large folio.

But although there is good reason not to batch up PMD-sized folios, we
might well benefit from batching a small number of low-order mTHPs (though
unclear how that "small number" limitation will be implemented).

So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
insulate those particular checks from future change.  Name preferred to
"folio_is_batchable" because large folios can well be put on a batch: it's
just the per-CPU LRU caches, drained much later, which need care.

Marked for stable, to counter the increase in lru_add_drain_all()s from
"mm/gup: check ref_count instead of lru before migration".

Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
Signed-off-by: Hugh Dickins <hughd@google.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Keir Fraser <keirf@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Li Zhe <lizhe.67@bytedance.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Shivank Garg <shivankg@amd.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Xu <weixugc@google.com>
Cc: Will Deacon <will@kernel.org>
Cc: yangge <yangge1116@126.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ Clean cherry-pick now into this tree ]
Signed-off-by: Hugh Dickins <hughd@google.com>
---
 include/linux/swap.h | 10 ++++++++++
 mm/gup.c             |  4 ++--
 mm/mlock.c           |  6 +++---
 mm/swap.c            |  2 +-
 4 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index f3e0ac20c2e8..63f85b3fee23 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -382,6 +382,16 @@ void folio_add_lru_vma(struct folio *, struct vm_area_struct *);
 void mark_page_accessed(struct page *);
 void folio_mark_accessed(struct folio *);
 
+static inline bool folio_may_be_lru_cached(struct folio *folio)
+{
+	/*
+	 * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting.
+	 * Holding small numbers of low-order mTHP folios in per-CPU LRU cache
+	 * will be sensible, but nobody has implemented and tested that yet.
+	 */
+	return !folio_test_large(folio);
+}
+
 extern atomic_t lru_disable_count;
 
 static inline bool lru_cache_disabled(void)
diff --git a/mm/gup.c b/mm/gup.c
index 4dd0eb70988b..d105817a0c9a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2376,13 +2376,13 @@ static unsigned long collect_longterm_unpinnable_folios(
 			continue;
 		}
 
-		if (drained == 0 &&
+		if (drained == 0 && folio_may_be_lru_cached(folio) &&
 				folio_ref_count(folio) !=
 				folio_expected_ref_count(folio) + 1) {
 			lru_add_drain();
 			drained = 1;
 		}
-		if (drained == 1 &&
+		if (drained == 1 && folio_may_be_lru_cached(folio) &&
 				folio_ref_count(folio) !=
 				folio_expected_ref_count(folio) + 1) {
 			lru_add_drain_all();
diff --git a/mm/mlock.c b/mm/mlock.c
index cde076fa7d5e..8c8d522efdd5 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -255,7 +255,7 @@ void mlock_folio(struct folio *folio)
 
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, mlock_lru(folio)) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
@@ -278,7 +278,7 @@ void mlock_new_folio(struct folio *folio)
 
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, mlock_new(folio)) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
@@ -299,7 +299,7 @@ void munlock_folio(struct folio *folio)
 	 */
 	folio_get(folio);
 	if (!folio_batch_add(fbatch, folio) ||
-	    folio_test_large(folio) || lru_cache_disabled())
+	    !folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		mlock_folio_batch(fbatch);
 	local_unlock(&mlock_fbatch.lock);
 }
diff --git a/mm/swap.c b/mm/swap.c
index d4cb4898f573..ff846915db45 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -223,7 +223,7 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
 		local_lock(&cpu_fbatches.lock);
 
 	if (!folio_batch_add(this_cpu_ptr(fbatch), folio) ||
-			folio_test_large(folio) || lru_cache_disabled())
+			!folio_may_be_lru_cached(folio) || lru_cache_disabled())
 		folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
 
 	if (disable_irq)
-- 
2.51.0.534.gc79095c0ca-goog