From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AAD7937AA8B for ; Mon, 2 Feb 2026 17:48:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770054540; cv=none; b=cBLGDAqGdJhBWNZAP/QP/F5hYAHvRQejLXBO62RCrMdtUbE7LZZoxrGzD0Gxe9z5YW7DxhfG9MLBbi0Nhl2D/ycIksvK3xCX4VBy7qgJubaqJ0NIuaSA4D7WWcAXBU5aEd5EObVtXwRYs2itL4e0NYIuFJCc4G8BBKyopaGtUZw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770054540; c=relaxed/simple; bh=plEqnRUAK0ai2JOEmKZ9oLZCk82AF0RJqqu0Ez826Zg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N5DV+z13GURz5RWlXFyyPb75KM/PAXah/OEfP6diiHc+lhLC52rl3pgoAbabU4Re3yY78C8+xnMz8lsqZ8SfMjTwFhjpTB30g7P2QdgtY8YAF/pMfnRGvf4sMWox9iQLSc11JlVEtTH+s/plZAWqdBr10IHa8jltLo2nZLWCCdU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=CB6Ox7N6; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="CB6Ox7N6" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4801eb2c0a5so46206505e9.3 for ; Mon, 02 Feb 2026 09:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770054537; x=1770659337; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YAotCLeZyiINnLo/dYSD4BE++0CoAWt914tHyyKTDIs=; b=CB6Ox7N6H9HtT2tHfl2w3kmYMVz95warzI/PfFnPNf5Lsis2Vx66VnCMclzZsSQOiO R256kxNcg03iRCkBSd0Gi4UhsCk1dVZcVD5v9g6oBpmwySZn5IsWAOqT0K7PyvSgDAmn H4H5Xj8CVq1WtvTp/eziTKKzTq5z4Wa0CObHWWA9mjqJ6ZL+/tPLLNJm24REK20SUmxz kyWCwlgNHcBdw66AGE3hlWFU2x1ApF4MqPeVLJet97QsMbrQVZmoWXD3swidNvOxWtXl I8dkk6iSYaVCILEWF4YYdvhHcTYBJznIAqXENekL0m+ASwmHo1RQ0o7Gasb+lJrUXtke z/LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770054537; x=1770659337; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YAotCLeZyiINnLo/dYSD4BE++0CoAWt914tHyyKTDIs=; b=NfDawebmFjWUY5vsagVkrf0VR1F4XrTNmprFkaMJ6WalnOM4TmK0X57imSqRigPCYR gqt2Adst1W1y/97yh2GNuM1v0ZPgwBn0xe5gEFWAn1pLIc4aZRzgkvNfVBQqYorTsxRP 9RTC3rbbzFlB8IIPlkwZzwWdJUoYQc6h5XkFaWJK22wW1F0oZJEwtqANgq3NlK2YKbDd rkLio8xCgSinv9y0FpyFx/VMAU+6BDsOgcgRfNCpn3paAFz49MInJaQg4DbMCDD/LvUP T2H3oaffId+GIQzcJEqX9rsZ2OMQXGPclCs3O775LUazBMdUkajvT1ABz8r5hxbvobxd dhdw== X-Forwarded-Encrypted: i=1; AJvYcCUwK91HzsAL7UyeGDtThp44jxm3cVk+5edGrBHe8BYUVJwimhTvVvyXaudo8MfMGYAQtLMnaLOf/OIjrAQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyFL/PPkluRv8mgNuVv64HsTVajFOBJCPPG9iUvpQy68MyVkeVL /Ko0vSRXssot8go8r/nqTzpW52ZVlTwe5RDkioX7Hah8vRlXP2ul3XAZ0bYYM/dELg== X-Gm-Gg: AZuq6aKoB5NPTTBJVs7aTIq8GZL2lvvqAh5ggViLrYT+os9QRqCgfgGXwmGchgNNXNy GGk9aBiCPlQQRuBf6u/q+BvCMGDKwjGOSWDg2JfIHBIZNQzgGhQyqL87NM2zQM24ad3mYy+Fms4 Wp1i7w2b/BGuatlPO74XUJOulPX/EqAZArKS4N1a7kQMgk4rGl3EveVN784vx9sDgG6lz2w99fO KNoi/ENdd0S2VDmi185K1fT3nnKZ3YK4ddh+wMgiixgTbFBHPbWb08NS0gozBbQczFcpUQVzs7X /LFvxs7KJ3sE3elUYToY5P5ZTMPEkTbubYgiWmhH2M4tT9jMiZwF5lIEexnre2blzfW08Qw8GnG QPGBQs+0oZfzV5PqksgTGfmP0y+O0qEfcbTnFBXTti+uZx004mtZTdMjVjtOcDAsrWiZIZtFuUt yn41Yq6jph5hi+iLj0lhrMaJlwxt++Ep2ghxW9YbcJqd81NU0= X-Received: by 2002:a05:600c:a00a:b0:471:1717:411 with SMTP id 5b1f17b1804b1-482db481be4mr157883855e9.24.1770054536894; Mon, 02 Feb 2026 09:48:56 -0800 (PST) Received: from elver.google.com ([2a00:79e0:2834:9:34d8:ac7:1851:db23]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-482dbcf9c3fsm115055905e9.4.2026.02.02.09.48.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 09:48:56 -0800 (PST) Date: Mon, 2 Feb 2026 18:48:47 +0100 From: Marco Elver To: Will Deacon Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Boqun Feng , Waiman Long , Bart Van Assche , llvm@lists.linux.dev, David Laight , Catalin Marinas , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/3] arm64: Optimize __READ_ONCE() with CONFIG_LTO=y Message-ID: References: <20260130132951.2714396-1-elver@google.com> <20260130132951.2714396-3-elver@google.com> <20260202160139.GF1282955@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.13 (2024-03-09) On Mon, Feb 02, 2026 at 03:36:40PM +0000, Will Deacon wrote: > I know that CONFIG_LTO practically depends on Clang, but it's a bit > grotty relying on that assumption here. Ideally, it would be > straightforward to enable the strong READ_ONCE() semantics on arm64 > regardless of the compiler. Does it matter for GCC versions that do not support LTO? Because I'm quite sure that if, one day, we add support for GCC LTO, that GCC version will be new enough that it'll just take the __typeof_unqual__() version and it'll "just work". The problem with older GCC versions was that their __auto_type did not actually strip qualifiers (which it should have) -- this was fixed at some point. On Mon, Feb 02, 2026 at 04:05PM +0000, Will Deacon wrote: > On Mon, Feb 02, 2026 at 05:01:39PM +0100, Peter Zijlstra wrote: > > On Mon, Feb 02, 2026 at 03:36:40PM +0000, Will Deacon wrote: > > > > > Since we're not providing acquire semantics for the non-atomic case, > > > what we really want is the generic definition of __READ_ONCE() from > > > include/asm-generic/rwonce.h here. The header inclusion mess prevents > > > that, but why can't we just inline that definition here for the > > > 'default' case? If TYPEOF_UNQUAL() leads to better codegen, shouldn't > > > we use that to implement __unqual_scalar_typeof() when it is available? > > > > We are? > > Great! Then I don't grok why we need to choose between > __unqual_scalar_typeof() and __typeof_unqual__() in the arch code. We > should just use the former and it will DTRT. The old __unqual_scalar_typeof() is still broken where __typeof_unqual__() is unavailable - for the arm64 + LTO case that'd be Clang <= 18, which we still have to support. We could probably just ignore the performance issue ('volatile' reload from stack, rare enough though given volatile variables are not usually allowed) for these older versions and just say "use the newer compiler to get better perf", but the 'const' issue will break the build: | --- a/arch/arm64/include/asm/rwonce.h | +++ b/arch/arm64/include/asm/rwonce.h | @@ -46,7 +46,7 @@ | #define __READ_ONCE(x) \ | ({ \ | auto __x = &(x); \ | - auto __ret = (__rwonce_typeof_unqual(*__x) *)__x; \ | + auto __ret = (__unqual_scalar_typeof(*__x) *)__x; \ | /* Hides alias reassignment from Clang's -Wthread-safety. */ \ | auto __retp = &__ret; \ | union { typeof(*__ret) __val; char __c[1]; } __u; \ Results in: | In file included from arch/arm64/kernel/asm-offsets.c:11: | In file included from ./include/linux/arm_sdei.h:8: | In file included from ./include/acpi/ghes.h:5: | In file included from ./include/acpi/apei.h:9: | In file included from ./include/linux/acpi.h:15: | In file included from ./include/linux/device.h:32: | In file included from ./include/linux/device/driver.h:21: | In file included from ./include/linux/module.h:20: | In file included from ./include/linux/elf.h:6: | In file included from ./arch/arm64/include/asm/elf.h:141: | ./include/linux/fs.h:1344:9: error: cannot assign to non-static data member '__val' with const-qualified type 'typeof (*__ret)' (aka 'struct fown_struct *const') | 1344 | return READ_ONCE(file->f_owner); | | ^~~~~~~~~~~~~~~~~~~~~~~~ | ./include/asm-generic/rwonce.h:50:2: note: expanded from macro 'READ_ONCE' | 50 | __READ_ONCE(x); \ | | ^~~~~~~~~~~~~~ | ./arch/arm64/include/asm/rwonce.h:76:13: note: expanded from macro '__READ_ONCE' | 76 | __u.__val = *(volatile typeof(*__x) *)__x; \ | | ~~~~~~~~~ ^ | ./include/linux/fs.h:1344:9: note: non-static data member '__val' declared const here | 1344 | return READ_ONCE(file->f_owner); | | ^~~~~~~~~~~~~~~~~~~~~~~~ | ./include/asm-generic/rwonce.h:50:2: note: expanded from macro 'READ_ONCE' | 50 | __READ_ONCE(x); \ | | ^~~~~~~~~~~~~~ | ./arch/arm64/include/asm/rwonce.h:52:25: note: expanded from macro '__READ_ONCE' | 52 | union { typeof(*__ret) __val; char __c[1]; } __u; \ | | ~~~~~~~~~~~~~~~^~~~~ ... and many many more such errors. It's an unfortunate mess today, but I hope sooner than later we bump the minimum compiler versions that we can just unconditionally use __typeof_unqual__() and delete __unqual_scalar_typeof(), __rwonce_typeof_unqual() workaround and all the other code that appears to be conditional on USE_TYPEOF_UNQUAL: % git grep USE_TYPEOF_UNQUAL arch/x86/include/asm/percpu.h:#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL)