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

[Peter Zijlstra]

On Wed, Oct 28, 2026 at 10:38:22AM +0800, Muchun Song wrote:
> 
> 
> On 2026/10/28 01:51, Kiryl Shutsemau wrote:
> > On Tue, Oct 27, 2026 at 10:03:54PM +0800, Muchun Song wrote:
> > > Therefore, I am kind of leaning towards removing the RO protection
> > > and restoring RW permissions to solve the race.
> > Okay, what about this:
> > 
> >  From e23ab850837b53cc79d57d58f1cfb4266e745c3d Mon Sep 17 00:00:00 2001
> > From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> > Date: Tue, 27 Oct 2026 17:23:47 +0000
> > Subject: [PATCH] mm/hugetlb_vmemmap: map the shared tail page writable
> > 
> > page_ref_add_unless_zero() reads the refcount and then updates it with
> > a cmpxchg.  A lockless get, such as a page cache lookup or a PFN
> > scanner, can read a non-zero refcount from a page that is then freed
> > and reused as a hugetlb tail page.  If HVO remaps its struct page to
> > the shared tail page in between, the cmpxchg writes to read-only
> > vmemmap:
> > 
> >      CPU0 (lockless get)               CPU1
> >      c = atomic_read(&page->_refcount)
> >                                        page freed
> >                                        page allocated as a hugetlb tail
> >                                        HVO remaps the struct page RO
> >      try_cmpxchg(&page->_refcount, &c, c + 1)
> >        -> write fault on read-only vmemmap
> > 
> > The refcount is zero by then and the compare fails, but LOCK CMPXCHG on
> > x86 writes anyway.  The kernel oopses when hugetlb pages are allocated
> 
> Is this an X86-specific issue? If not, I suggest a more generic
> description.

AFAICT most architectures that implement single compare-and-swap
instructions are affected, with the possible exception of s390.

That is, sparc, arm64-lse, riscv-Zacas, loonarch-amocas, openrisc (and
ia64 for those people keeping the out-of-tree port alive) all require
write protection to begin cmpxchg.

All the LL/SC architectures should be fine, they'll never get to the SC
part.