Re: Where to put page->memdesc initially

[Matthew Wilcox <willy@infradead.org>]

On Tue, Sep 02, 2025 at 06:15:14PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 02, 2025 at 10:06:05PM +0100, Matthew Wilcox wrote:
> 
> > I'm concerned by things like compaction that are executing
> > asynchronously and might see a page mid-transition.  Or something like
> > GUP or lockless pagecache lookup that might get a stale page
> > pointer.
> 
> At least GUP fast obtains a page refcount before touching the rest of
> struct page, so I think it can't see those kinds of races since the
> page shouldn't be transitioning with a non-zero refcount?

OK, so ...

 - For folios, there's already no such thing as a page refcount (you may
   already know this and are just being slightly sloppy while
   speaking).  If you attempt to access the refcount on a tail page,
   you're silently redirected to the folio refcount.

 - That's not going to change with memdescs; for pages which are part of
   a memdesc, attempting to acess the page's refcount will redirect to
   the folio's refcount.

What GUP-fast will do once we get to Page2025 is:

 - READ_ONCE(page->memdesc)
 - Check that the bottom bits match a folio.  If not, fall back to
   GUP-slow (or retry; I forget the details).
 - tryget the refcount, if fail fall back/retry
 - if (READ_ONCE(page->memdesc) != memdesc) { folio_put(); retry/fallback }
 - yay, we succeeded.

So that's all a little more complicated with two places to check as
an intermediate state, but I think it's doable.  It's just fiddly.