arch/arm64/Kconfig | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
From: Lukas Bulwahn <lukas.bulwahn@redhat.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.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
---
CC-ing Vegard and Kees to check that the use of the transitional attribute
is done as it is intended.
Note I have set myself a reminder in my personal calendar for three years
in the future from now to remove the transitional Kconfig definition,
assuming by then all users that maintain their Kconfig fragments with
ARM64_USE_LSE_ATOMICS included have transitioned (if such users exist at
all).
arch/arm64/Kconfig | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3fb4603c0e16..e113555ef6cd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1875,11 +1875,8 @@ config ARM64_PAN
instruction if the cpu does not implement the feature.
config ARM64_LSE_ATOMICS
- bool
- default ARM64_USE_LSE_ATOMICS
-
-config ARM64_USE_LSE_ATOMICS
bool "Atomic instructions"
+ default ARM64_USE_LSE_ATOMICS
default y
help
As part of the Large System Extensions, ARMv8.1 introduces new
@@ -1890,6 +1887,13 @@ config ARM64_USE_LSE_ATOMICS
atomic routines. This incurs a small overhead on CPUs that do
not support these instructions.
+config ARM64_USE_LSE_ATOMICS
+ bool
+ transitional
+ help
+ Transitional config for ARM64_USE_LSE_ATOMICS to ARM64_LSE_ATOMICS
+ migration.
+
endmenu # "ARMv8.1 architectural features"
menu "ARMv8.2 architectural features"
--
2.52.0[+Marc]
On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote:
> From: Lukas Bulwahn <lukas.bulwahn@redhat.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?
Will
On Mon, 05 Jan 2026 20:50:41 +0000,
Will Deacon <will@kernel.org> wrote:
>
> [+Marc]
>
> On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote:
> > From: Lukas Bulwahn <lukas.bulwahn@redhat.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@kernel.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@kernel.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(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 93173f0a09c7d..b6f57cc1e4df8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1873,22 +1873,6 @@ config ARM64_PAN
The feature is detected at runtime, and will remain as a 'nop'
instruction if the cpu does not implement the feature.
-config ARM64_LSE_ATOMICS
- bool
- default ARM64_USE_LSE_ATOMICS
-
-config ARM64_USE_LSE_ATOMICS
- bool "Atomic instructions"
- default y
- help
- As part of the Large System Extensions, ARMv8.1 introduces new
- atomic instructions that are designed specifically to scale in
- very large systems.
-
- Say Y here to make use of these instructions for the in-kernel
- atomic routines. This incurs a small overhead on CPUs that do
- not support these instructions.
-
endmenu # "ARMv8.1 architectural features"
menu "ARMv8.2 architectural features"
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index e1d30ba99d016..f463a654a2bbd 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -671,7 +671,6 @@ u32 aarch64_insn_gen_extr(enum aarch64_insn_variant variant,
enum aarch64_insn_register Rn,
enum aarch64_insn_register Rd,
u8 lsb);
-#ifdef CONFIG_ARM64_LSE_ATOMICS
u32 aarch64_insn_gen_atomic_ld_op(enum aarch64_insn_register result,
enum aarch64_insn_register address,
enum aarch64_insn_register value,
@@ -683,28 +682,6 @@ u32 aarch64_insn_gen_cas(enum aarch64_insn_register result,
enum aarch64_insn_register value,
enum aarch64_insn_size_type size,
enum aarch64_insn_mem_order_type order);
-#else
-static inline
-u32 aarch64_insn_gen_atomic_ld_op(enum aarch64_insn_register result,
- enum aarch64_insn_register address,
- enum aarch64_insn_register value,
- enum aarch64_insn_size_type size,
- enum aarch64_insn_mem_atomic_op op,
- enum aarch64_insn_mem_order_type order)
-{
- return AARCH64_BREAK_FAULT;
-}
-
-static inline
-u32 aarch64_insn_gen_cas(enum aarch64_insn_register result,
- enum aarch64_insn_register address,
- enum aarch64_insn_register value,
- enum aarch64_insn_size_type size,
- enum aarch64_insn_mem_order_type order)
-{
- return AARCH64_BREAK_FAULT;
-}
-#endif
u32 aarch64_insn_gen_dmb(enum aarch64_insn_mb_type type);
u32 aarch64_insn_gen_dsb(enum aarch64_insn_mb_type type);
u32 aarch64_insn_gen_mrs(enum aarch64_insn_register result,
diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
index 3129a5819d0e0..1e77c45bb0a83 100644
--- a/arch/arm64/include/asm/lse.h
+++ b/arch/arm64/include/asm/lse.h
@@ -4,8 +4,6 @@
#include <asm/atomic_ll_sc.h>
-#ifdef CONFIG_ARM64_LSE_ATOMICS
-
#define __LSE_PREAMBLE ".arch_extension lse\n"
#include <linux/compiler_types.h>
@@ -27,11 +25,4 @@
#define ARM64_LSE_ATOMIC_INSN(llsc, lse) \
ALTERNATIVE(llsc, __LSE_PREAMBLE lse, ARM64_HAS_LSE_ATOMICS)
-#else /* CONFIG_ARM64_LSE_ATOMICS */
-
-#define __lse_ll_sc_body(op, ...) __ll_sc_##op(__VA_ARGS__)
-
-#define ARM64_LSE_ATOMIC_INSN(llsc, lse) llsc
-
-#endif /* CONFIG_ARM64_LSE_ATOMICS */
#endif /* __ASM_LSE_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c840a93b9ef95..547ccf28f2893 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2560,7 +2560,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, PAN, PAN3)
},
#endif /* CONFIG_ARM64_EPAN */
-#ifdef CONFIG_ARM64_LSE_ATOMICS
{
.desc = "LSE atomic instructions",
.capability = ARM64_HAS_LSE_ATOMICS,
@@ -2568,7 +2567,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.matches = has_cpuid_feature,
ARM64_CPUID_FIELDS(ID_AA64ISAR0_EL1, ATOMIC, IMP)
},
-#endif /* CONFIG_ARM64_LSE_ATOMICS */
{
.desc = "Virtualization Host Extensions",
.capability = ARM64_HAS_VIRT_HOST_EXTN,
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 53bf70126f81d..6cbcec041a9dd 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -1700,7 +1700,6 @@ int __kvm_find_s1_desc_level(struct kvm_vcpu *vcpu, u64 va, u64 ipa, int *level)
}
}
-#ifdef CONFIG_ARM64_LSE_ATOMICS
static int __lse_swap_desc(u64 __user *ptep, u64 old, u64 new)
{
u64 tmp = old;
@@ -1725,12 +1724,6 @@ static int __lse_swap_desc(u64 __user *ptep, u64 old, u64 new)
return ret;
}
-#else
-static int __lse_swap_desc(u64 __user *ptep, u64 old, u64 new)
-{
- return -EINVAL;
-}
-#endif
static int __llsc_swap_desc(u64 __user *ptep, u64 old, u64 new)
{
diff --git a/arch/arm64/lib/insn.c b/arch/arm64/lib/insn.c
index 4e298baddc2e5..cc5b40917d0dd 100644
--- a/arch/arm64/lib/insn.c
+++ b/arch/arm64/lib/insn.c
@@ -611,7 +611,6 @@ u32 aarch64_insn_gen_load_store_ex(enum aarch64_insn_register reg,
state);
}
-#ifdef CONFIG_ARM64_LSE_ATOMICS
static u32 aarch64_insn_encode_ldst_order(enum aarch64_insn_mem_order_type type,
u32 insn)
{
@@ -755,7 +754,6 @@ u32 aarch64_insn_gen_cas(enum aarch64_insn_register result,
return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RS, insn,
value);
}
-#endif
u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst,
enum aarch64_insn_register src,
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index b6eb7a465ad24..5ce82edc508e4 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -776,7 +776,6 @@ static int emit_atomic_ld_st(const struct bpf_insn *insn, struct jit_ctx *ctx)
return 0;
}
-#ifdef CONFIG_ARM64_LSE_ATOMICS
static int emit_lse_atomic(const struct bpf_insn *insn, struct jit_ctx *ctx)
{
const u8 code = insn->code;
@@ -843,12 +842,6 @@ static int emit_lse_atomic(const struct bpf_insn *insn, struct jit_ctx *ctx)
return 0;
}
-#else
-static inline int emit_lse_atomic(const struct bpf_insn *insn, struct jit_ctx *ctx)
-{
- return -EINVAL;
-}
-#endif
static int emit_ll_sc_atomic(const struct bpf_insn *insn, struct jit_ctx *ctx)
{
--
2.47.3
--
Without deviation from the norm, progress is not possible.
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@kernel.org> wrote:
> >
> > [+Marc]
> >
> > On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote:
> > > From: Lukas Bulwahn <lukas.bulwahn@redhat.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@kernel.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@kernel.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
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@kernel.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@kernel.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
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@kernel.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@kernel.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
On Wed, 07 Jan 2026 15:58:28 +0000,
Will Deacon <will@kernel.org> 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@kernel.org> wrote:
> > >
> > > [+Marc]
> > >
> > > On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote:
> > > > From: Lukas Bulwahn <lukas.bulwahn@redhat.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@kernel.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@kernel.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.
Ack. Series posted at [1].
Thanks,
M.
[1] https://lore.kernel.org/r/20260107180701.2858276-1-maz@kernel.org
--
Without deviation from the norm, progress is not possible.
© 2016 - 2026 Red Hat, Inc.