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

On Fri, 28 Aug 2026 01:57:25 -0700 (PDT)
Hugh Dickins [off-list ref] wrote:

On Thu, 27 Aug 2026, Claudio Imbrenda wrote:

quoted

On Thu, 27 Aug 2026 01:49:12 -0700 (PDT)
Hugh Dickins [off-list ref] wrote:  

...

quoted

quoted

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)

...

quoted

quoted

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

quoted

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