Re: [PATCH v4 0/2] mm: improve folio refcount scalability

[Matthew Wilcox]

On Sun, Jun 21, 2026 at 09:34:47PM +0000, Gladyshev Ilya wrote:
> June 21, 2026 at 7:46 AM, Linus Torvalds wrote:
> > 
> > On Sat, 20 Jun 2026 at 11:19, <ilya.gladyshev@xxxxxxxxx> wrote:
> > 
> > > 
> > > T2: optimistic get() [0 -> 1]
> > > T2: put page back [1 -> 0]
> > > T2: calls dtor for type X, returns into the allocator
> > > 
> > Which optimistic getter does this?
> 
> If I understood you correctly, you are talking about the scenario where
> an optimistic getter took a refcount on the stolen page, so the validity
> check in the XArray will fail. And this scenario does indeed work normally.
> 
> This "ABA" happens if the optimistic getter successfully gets a refcount
> on a valid page, so the full T2 execution looks like this:
> 
> T2: optimistic get() [0 -> 1]
> T2: re-checks page [OK]

I don't think that can happen.  Or maybe it can and we need to add
some barriers.  The page is always removed from visibility (whether
we're talking about a page cache lookup or a page table lookup), then
the refcount is decremented.  I hope we have enough barriers in place
to ensure that the refcount decrement is observed after the removal of
the PTE entry or the XArray entry.

But I'm not sure why the folio_put() after a speculative get avoids this
problem; why do we need the recheck to be successful to hit this race?

> T2: *normally works with this page*
> T2: frees page [1 -> 0 -> FROZEN]
> T2: calls dtor for type X, returns into the allocator
> 
> ... T3 reuses the page, T1 wakes up and conflicts ...
> 
> T1 basically needs to sleep for a veeery long time to miss full T2 & T3
> execution. 
> 
> > I didn't go back and look at the series, but isn't the rule that the code does:
> > 
> >  - optimistic get
> > 
> >  - then check that the folio is still valid (*not* using the page
> > count, but by re-looking it up elsewhere, typically the address space
> > mapping)
> > 
> >  - put the page if it wasn't valid
> > 
> >  - if it goes to zero, there's no destructor inherent in that
> > 
> >  - everybody who sees it go to zero - optimistic or not - does the
> > "zero to frozen" cmpxchg
> 
> The problem is -- the zero you've seen and zero you are trying to CAS
> can be different zeros if the page gets reused fast enough.
> (Or couldn't and I am just confused :) )
> 
> >  - only *one* of those will succeed, and *THAT* triggers the destructor
> >
> >
> > IOW, the transition to zero is not special per se and has no
> > destructor. All it triggers is the "now we try to mark it frozen"
> > phase.
> > 
> > At least that was my mental picture.
> > 
> > Was I wrong? Am I just confused? Wouldn't be the first time.
> > 
> >  Linus
> >