linux-kernel - Re: [PATCH] arm64: Kconfig: deprecate redundant ARM64_USE_LSE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aW9xlz0bMw1koatd@willie-the-truck>
Date: Tue, 20 Jan 2026 12:14:15 +0000
From: Will Deacon <will@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Marc Zyngier <maz@...nel.org>, Lukas Bulwahn <lbulwahn@...hat.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-arm-kernel@...ts.infradead.org,
	Mark Rutland <mark.rutland@....com>,
	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 Wed, Jan 07, 2026 at 11:07:03PM +0100, Arnd Bergmann wrote:
> On Wed, Jan 7, 2026, at 16:58, Will Deacon wrote:
> > 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:
> >> 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.
> 
> I'm not entirely convinced by the direction. Removing compile-time
> options and complexity from #ifdef blocks is clearly an advantage,
> but I'm a bit worried about at least the ARM64_USE_LSE_ATOMICS 
> option still being valuable.
> 
> The boot-time patching for all atomics adds complexity as well, and
> being able to configure it out can be helpful in a number of
> scenarios:
> 
> - I've seen several scenarios where code size is extremely important,
>   and being able to compile out any runtime-detected features 
>   saves some space. In a defconfig kernel, this is about 1.1% of .text.
>   Being able to select just the LSE version without the patching
>   may be even more valuable these days, but almost
>   all embedded systems I see are still ARMv8.0 (Cortex-A53 and
>   Cortex-A35) without LSE.
> - We have an experimental patch set for CONFIG_XIP_KERNEL on arm64,
>   which inherently requires not patching at all, and requires
>   the opposite patches for other features and errata workarounds.
> - The amount of nested macros and inline functions for the arm64
>   atomics is large enough to slow down compilation, #including
>   linux/spinlock.h shouldn't really result in >1MB of preprocessed
>   source code. (this is a much harder problem to solve)

In the absence of a concerted and persistent upstream effort to solve
some of these problems, I think retaining ARM64_USE_LSE_ATOMICS is
a tiny drop in the ocean and yet its presence does lead to build
breakages and additional testing burden today, which we could avoid.

So I'm inclined to merge Marc's changes and if folks aggressively want
to optimise the kernel's memory footprint in future, perhaps they can
try to implement some of your suggestions above (such as forcing the
LSE atomics into the compiled Image).

Will