Re: [PATCH 20/25] s390/fbatch: no lru_add_drain_all() in s390_wiggle_split_folio()

[Claudio Imbrenda]

On Fri, 28 Aug 2026 01:57:25 -0700 (PDT)
Hugh Dickins <hughd@xxxxxxxxxx> wrote:

> On Thu, 27 Aug 2026, Claudio Imbrenda wrote:
> > On Thu, 27 Aug 2026 01:49:12 -0700 (PDT)
> > Hugh Dickins <hughd@xxxxxxxxxx> wrote:  
> ...
> > > 
> > > I most certanly don't know s390 or that code well enough to guarantee
> > > you that no stray references to mapped folios can remain there. What I
> > > can guarantee is that no references, of the kind which lru_add_drain_all()
> > > used to be needed to remove, can exist there: so there will no longer
> > > be any point in s390 (or others) calling it for that reason, to help
> > > split_folio() to succeed.  
> > 
> > we are not using it to help split_folio() succeed (although that's a
> > pleasant side effect). We need it even for small pages, to guarantee
> > that no extra reference from LRU is present on the page.  
> 
> Ah, thanks for explaining, that all makes more sense to me now.
> I remember from when working on memfd write sealing years ago, it too

yep, we use it to make sure no I/O is happening on the page while it's
transitioning

> had to be able to account for every page reference before proceeding,
> and resorted to lru_add_drain() and lru_add_drain_all() to help -
> those now removed in 14/25 of this series.

I see, then I guess we're good (see below)

> 
> ...
> > > If Barry's relaxation goes in before my drainage changes, then
> > > there is value in that s390 lru_add_drain_all() in the interim.  
> > 
> > hmmm so, should it stay for now, then?  
> 
> The s390 lru_add_drain_all() should go whenever the rest of this
> series goes in. It's not essential for the callers to be removed
> immediately, no correctness requirement; but nicer if we can get
> rid of most of them. I'm hoping this patch can just go in along
> with the rest via the mm tree - and I'm sure you can trust David
> Hildenbrand to understand and protect s390's interests.

so if I understand correctly, with this series the LRU caches
will never hold extra references (as in refcount) on pages anymore,
therefore calling lru_add_drain_all() will never decrease the refcount
on any of the pages that are in any of the LRU caches

in that case the lru drain can indeed go

> 
> > 
> > also: I'm working on completely reworking how the transition from
> > non-secure to secure is handled, with the explicit goal of getting rid
> > of that kludge we are currently using. That will also get rid of the
> > lru drain. But it will take some time (I hope to have something by the
> > end of the year)  
> 
> Good luck!
> Hugh