Message-ID: <aV6CpBCvr37mcv7W@willie-the-truck>
Date: Wed, 7 Jan 2026 15:58:28 +0000
From: Will Deacon <will@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Lukas Bulwahn <lbulwahn@...hat.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-arm-kernel@...ts.infradead.org,
	Mark Rutland <mark.rutland@....com>, Arnd Bergmann <arnd@...db.de>,
	Vegard Nossum <vegard.nossum@...cle.com>,
	Kees Cook <kees@...nel.org>, kernel-janitors@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Lukas Bulwahn <lukas.bulwahn@...hat.com>
Subject: Re: [PATCH] arm64: Kconfig: deprecate redundant ARM64_USE_LSE_ATOMICS

On Tue, Jan 06, 2026 at 01:54:39PM +0000, Marc Zyngier wrote:
> On Mon, 05 Jan 2026 20:50:41 +0000,
> Will Deacon <will@...nel.org> wrote:
> > 
> > [+Marc]
> > 
> > On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote:
> > > From: Lukas Bulwahn <lukas.bulwahn@...hat.com>
> > > 
> > > Currently, the config options ARM64_USE_LSE_ATOMICS and ARM64_LSE_ATOMICS
> > > are equivalent, i.e., ARM64_LSE_ATOMICS is true if and only if
> > > ARM64_USE_LSE_ATOMICS is true.
> > > 
> > > Prior to commit 395af861377d ("arm64: Move the LSE gas support detection to
> > > Kconfig")---included in v5.6-rc1---only the config option ARM64_LSE_ATOMICS
> > > was defined, and the check for gas support was done in the Makefile. This
> > > mentioned commit then introduces the config option ARM64_USE_LSE_ATOMICS to
> > > be the promptable option, and changes the semantics of ARM64_LSE_ATOMICS to
> > > check for the gas support.
> > > 
> > > Note that there is then some minor refactoring in commit 2decad92f473
> > > ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically"), putting this
> > > gas support check into its own config option AS_HAS_LSE_ATOMICS, but the
> > > logic remains the same. Since every binutils version defined suitable for
> > > kernel compilation then eventually included the required support, the
> > > config option AS_HAS_LSE_ATOMICS and the dependency was dropped with
> > > commit 2555d4c68720 ("arm64: drop binutils version checks"). This then
> > > makes ARM64_USE_LSE_ATOMICS and ARM64_LSE_ATOMICS equivalent. Hence, one
> > > of the two config options can be dropped now.
> > > 
> > > Considerations for the decision which config option to drop:
> > > 
> > >   - ARM64_USE_LSE_ATOMICS is promptable by the user since its introduction
> > >     in 2020. So there might be some Kconfig fragments that define this
> > >     config option and expect that this then implies ARM64_LSE_ATOMICS to be
> > >     set. However, within the kernel tree, there is no existing config file
> > >     referring to that option. So, it is unlikely to be widely used.
> > >   - ARM64_LSE_ATOMICS is used in nine places within the arm64 directory in
> > >     the current kernel tree.
> > >   - ARM64_USE_LSE_ATOMICS is the only config option that contains the infix
> > >     string _USE_ to enable support and use of an arm64 architectural
> > >     feature. However, there is not a very stringent and consistent naming
> > >     convention for Kconfig options throughout the kernel tree anyway.
> > >   - The use of the transitional attribute allows to simplify transitioning
> > >     to a different Kconfig symbol name, but also adds some intermediate
> > >     definition to be removed later eventually.
> > > 
> > > After thoughtful consideration, keep ARM_LSE_ATOMICS and remove
> > > ARM64_USE_LSE_ATOMICS in a two-step approach, first deprecate
> > > ARM64_USE_LSE_ATOMICS with the transitional attribute here and then plan
> > > to completely remove it in two or three years with a further dedicated
> > > commit then.
> > 
> > Marc was talking about removing ARM64_LSE_ATOMICS entirely the other day
> > after it bit him with a KVM change. If all supported assemblers understand
> > the LSE instructions, let's just do that?
> 
> That'd be my preferred option. Having config options for things that
> we can detect and patch at runtime makes coverage a lot more difficult
> than it should be. I'd also love to kill CONFIG_ARM64_PAN, for
> example. In any case, here's my take on this, based on -rc4.
> 
> Thanks,
> 
> 	M.
> 
> From 3ab18194eefd2017fb1cea6764adb0634f5946da Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz@...nel.org>
> Date: Tue, 6 Jan 2026 13:44:14 +0000
> Subject: [PATCH] arm64: Unconditionally enable LSE support
> 
> LSE atomics have been in the architecture since ARMv8.1 (released in
> 2014), and are hopefully supported by all modern toolchains.
> 
> Drop the optional nature of LSE support in the kernel, and always
> compile the support in, as this really is very little code. LL/SC
> still is the default, and the switch to LSE is done dynamically.
> 
> Signed-off-by: Marc Zyngier <maz@...nel.org>
> ---
>  arch/arm64/Kconfig             | 16 ----------------
>  arch/arm64/include/asm/insn.h  | 23 -----------------------
>  arch/arm64/include/asm/lse.h   |  9 ---------
>  arch/arm64/kernel/cpufeature.c |  2 --
>  arch/arm64/kvm/at.c            |  7 -------
>  arch/arm64/lib/insn.c          |  2 --
>  arch/arm64/net/bpf_jit_comp.c  |  7 -------
>  7 files changed, 66 deletions(-)

I think we should go ahead with this.

Initially, I thought we'd need some surgery to cpufeature.c so that
cpus_have_final_cap() could take the _likely_ path for LSE but it looks
like that's only relevant for KVM's AT handling and the common atomic_t
APIs use alternative_has_cap_likely() already.

If we do something similar for PAN, then system_uses_hw_pan() probably
wants the polarity switching from unlikely to likely.

Will

Powered by blists - more mailing lists