From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=90.155.92.199 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793194497; b=CAe7nnvoxerlWqtn6je8FGJDMpJFiRmugWMXkmclHfnBkwqbgTwtmBdKRLCztexuhzwh ud4hSxbm/YoAi6hPCGTbGmQ9vqR0eVJC3hsCZP+Q6J/Rjj2Ru9yKixbB1m9G8UZyL1Web DXpJSvuJyVXIcJUu1BEV7aGSQ7D16CWmIgMPwljScj8IquLhsCaylyChWtqLJrbjWjXzt JHqaBsX2rT8hommIyEz28x/M72KwxaoBOQRHCTBwr9pAW/fWGnmWxr5hRFIP4ZGh+34Mm 1x6msOnH9bM2r7kpySGSjxAqoGznQLDZT45aOPBTxGj+Jq23mU/bAU/jBPfpDOHmsYg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793194497; h=DMARC-Filter:DKIM-Signature:Received:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=K5sU8ZAJRz6gFhM4gDWxCHu2kvyqTC/PTTWhoAieCGY=; b=zvz2UrUH8e2e/TZJ3eFZ3Y+aFSccgRLTqSKJJfiz01mtZ4xDpSbUrAtFQKXyG3/PS8pE K5OPGuezyG+6eKoVN6C/yCvp4AaxsjFjp2z2+hQ3ZUEBEVoZShMPWF1LUErzFf776dpw5 CgRZEqzWfln7AOB/6DN8+8LHUXOrJc0VZmoRZx/jjWvwFBDu5c2Kd4blVzAS1+c1JD6zv tyoeMJSWMomuCNzmP3zvckVeowHSi3yJxcOQ2vK5dgf3/83yl6msvZLEF+axMnJgS0CjJ RPEqw+yWod0GfyiWjYL9pKvIHLcrNwnCm7c3CO4O/IynqnQpxkTeFSLjAsXTsa5GBWQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=desiato.20200630 header.b=WQTo7RRj; arc=none smtp.remote-ip=90.155.92.199 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC7A6606A31A; Wed, 28 Oct 2026 13:34:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org DC7A6606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=desiato.20200630 header.b=WQTo7RRj DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=K5sU8ZAJRz6gFhM4gDWxCHu2kvyqTC/PTTWhoAieCGY=; b=WQTo7RRjUws4wLzC6TxpAmx57w qcq5fCMagtfKad2FmcZhLNiyNmxBTF8/cvyU5FhHuyznlY2ota9MN31xYDxFIv2Erfp4aIicHdOEl E2jxLk1iu6UVgBFuNZDHQbP8i5O71tuJIGJbKRCf70a3PNnSQKK+sWlOzaRMzfKYFkbHgL5lDL9Vp ZvXgetdmOXoLVKHD/1ZDYuRo7eMc1PaJvukhM56Ia68PICeBLH2PimR6BGNHj7GsDJbTI86FtVG5t W0wLnsMXdRptmezamho6yQr8A3y96kAxjX7Nk07pkHXtbr6zoq0TtEiKMjF427WJnVaamNRv1dQ0Y /t33+Xow==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.100.1 #2 (Red Hat Linux)) id 1xM3ne-0000000G0rh-0VGE; Wed, 28 Oct 2026 13:34:43 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id E42F1300DB9; Wed, 28 Oct 2026 14:34:39 +0100 (CET) Date: Wed, 28 Oct 2026 14:34:39 +0100 From: Peter Zijlstra To: Kiryl Shutsemau Cc: Muchun Song , "David Hildenbrand (Arm)" , Andrew Morton , Matthew Wilcox , Usama Arif , Frank van der Linden , Oscar Salvador , Mike Rapoport , Vlastimil Babka , Lorenzo Stoakes , Zi Yan , Baoquan He , Michal Hocko , Johannes Weiner , Jonathan Corbet , Huacai Chen , WANG Xuerui , Palmer Dabbelt , Paul Walmsley , Albert Ou , Alexandre Ghiti , 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 , Andy Lutomirski Subject: Re: [PATCHv7 13/18] mm: Drop fake head checks Message-ID: <20261028133439.GK2668804@noisy.programming.kicks-ass.net> References: <070DDE5C-2183-4A8B-AC2D-891CAE15E581@linux.dev> <4A32F5E6-977D-4720-8723-B19AFBC08FCF@linux.dev> <7cb3dd91-f518-49b6-b311-9ec807b3c63b@linux.dev> <20261028080635.GD2668804@noisy.programming.kicks-ass.net> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Oct 28, 2026 at 12:58:11PM +0000, Kiryl Shutsemau wrote: > On Wed, Oct 28, 2026 at 09:06:35AM +0100, Peter Zijlstra wrote: > > 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)" > > > > 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. > > Only architectures with HVO matter here: x86-64, riscv and loongarch. > arm64 has had it disabled since 060a2c92d1b6. Per that commit, could it be re-enabled now that its no longer marked RO? > riscv and loongarch implement atomic_fetch_add_unless() with LL/SC only, > no CAS variant, so they see the zero at the load. That leaves x86. Ah yes, I only looked at the cmpxchg implementation rather than the fetch_add_unless :/