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: <7b7ac65c-773e-48fe-a335-c49b6ef9a0e8@app.fastmail.com>
Date: Wed, 07 Jan 2026 23:07:03 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Will Deacon" <will@...nel.org>, "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>,
 "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 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)

      Arnd