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

[Hugh Dickins]

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
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.

...
> > 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.

> 
> 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