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

From: Peter Zijlstra <peterz@infradead.org>
To: Muchun Song <muchun.song@linux.dev>
Cc: Kiryl Shutsemau <kas@kernel.org>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	Usama Arif <usamaarif642@gmail.com>,
	Frank van der Linden <fvdl@google.com>,
	Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Zi Yan <ziy@nvidia.com>, Baoquan He <bhe@redhat.com>,
	Michal Hocko <mhocko@suse.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	kernel-team@meta.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCHv7 13/18] mm: Drop fake head checks
Date: Wed, 28 Oct 2026 09:06:35 +0100	[thread overview]
Message-ID: <20261028080635.GD2668804@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <7cb3dd91-f518-49b6-b311-9ec807b3c63b@linux.dev>

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@kernel.org>
> > 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.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv