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