Re: [PATCHv7 13/18] mm: Drop fake head checks

[Peter Zijlstra]

On Tue, Oct 27, 2026 at 12:22:56PM +0000, Kiryl Shutsemau wrote:
> On Tue, Oct 27, 2026 at 01:13:23PM +0100, Peter Zijlstra wrote:
> > On Tue, Oct 27, 2026 at 12:00:47PM +0000, Kiryl Shutsemau wrote:
> > 
> > > Fair enough. Here's some context.
> > > 
> > > HVO (HugeTLB Vmemmap Optimization) frees most of the memmap of a hugetlb
> > > folio by remapping the struct pages after the first vmemmap page to a
> > > shared page, mapped read-only.
> > > 
> > > Every lockless get of a page reference (e.g. page cache lookup, PFN
> > > scanners) relies on page_ref_add_unless_zero(), which is
> > > atomic_add_unless(&page->_refcount, nr, 0).
> > > 
> > > The page can be freed and reused between finding it and the get; the
> > > zero refcount is what makes the get fail. The race:
> > > 
> > >   lockless get                        other CPU
> > >   c = atomic_read(&page->_refcount)
> > >   c != 0
> > >                                       page freed
> > >                                       page allocated as a hugetlb tail
> > >                                       HVO remaps it read-only
> > >   try_cmpxchg(&page->_refcount, &c, c + nr)
> > >     -> write fault on read-only vmemmap
> > 
> > I missed a little something here; page->_refcount is in the page-frame;
> > how does the page itself being RO affect this?
> 
> Emm. I am not sure I follow the question.
> 
> The memory itself is not touched. HVO remaps the vmemmap, the array of
> struct pages: the part that holds the folio's tail struct pages points
> to the shared page, mapped PAGE_KERNEL_RO. So it is the struct page,
> and its _refcount, that is read-only.
> 
> For a 2M folio with 4K pages, its struct pages take 8 pages of vmemmap;
> the last 7 of them map to that one RO page.

Like I just explain to David on IRC; my brain has a 1:1 relation between
PFN and struct page. It makes no sense for struct page to be RO, ever.

Anyway, let me try and figure out how all this works, this is 'weird'.