Re: [PATCH v6 2/6] riscv: build kernel atomics from LR/SC when Zaamo is disabled

[Jisheng Zhang <jszhang@kernel.org>]

On Tue, Nov 10, 2026 at 07:02:48PM +0000, Conor Dooley wrote:
> On Tue, Nov 10, 2026 at 03:20:59PM +0200, Vladimir Kondratiev wrote:
> > The A extension is Zaamo plus Zalrsc. On some CPUs Zaamo is present
> > only formally. MIPS P8700 traps every AMO instruction into M-mode and
> > emulates it there, so the extension is supported but very slow. A
> > typical uncontended atomic increment costs:
> > 
> >   native AMO                                     2..5 cycles
> >   LR/SC, private L1 reservation monitor         6..12 cycles
> >   LR/SC, PoC (L2) reservation monitor       about 40 cycles
> >   AMO emulated by an M-mode trap           about 600 cycles
> > 
> > The last two were measured on the eyeq7h hardware. On such a CPU the
> > kernel must use LR/SC for every atomic.
> > 
> > Add RISCV_ISA_ZAAMO, default y. The default keeps "a" in -march and
> > the generated code unchanged. When it is disabled, -march carries
> > _zalrsc instead of "a", and atomic_*, bitops, xchg, futex and the
> > early boot code use LR/SC loops. The sequence is chosen with the
> > preprocessor, on CONFIG_RISCV_ISA_ZAAMO like the other ISA options in
> > the headers, because the assembler rejects AMO mnemonics once -march
> > lacks Zaamo. A kernel built this way runs on any hart that implements
> > A; it just does not use AMO. It is therefore a plain option, not a
> > NONPORTABLE one, and the hart keeps advertising "a" to userspace,
> > which is true.
> > 
> > The LR/SC loops follow the ordering convention of the existing ones
> > in cmpxchg.h, from commit 5ce6c1f3535f ("riscv/atomic: Strengthen
> > implementations with fences") and commit 1d84afaf0252 ("riscv: Fix
> > fully ordered LR/SC xchg[8|16]() implementations"): a fully ordered
> > operation is lr, sc.rl and a trailing fence rw,rw; acquire is lr.aq
> > with a plain sc; release is a plain lr with sc.rl. The futex loop is
> > bounded to 128 retries and returns -EAGAIN after that, as arm64 does,
> > because userspace can keep the word changing from another thread and
> > futex_wake_op() retries on -EAGAIN anyway.
> > 
> > Zabha, Zacas and the ssamoswap instruction of Zicfiss are AMO
> > instructions, so RISCV_ISA_ZABHA, RISCV_ISA_ZACAS and RISCV_USER_CFI
> > depend on RISCV_ISA_ZAAMO. The riscv64imac Rust target emits AMO too,
> > so RUSTC_SUPPORTS_RISCV depends on it as well.
> > 
> > The choice is made at compile time rather than with alternatives.
> > Nearly every CPU has a native A extension, and an alternative would
> > inflate all those kernels with the nops needed to pad one AMO to the
> > size of an LR/SC loop, at every atomic site, for the benefit of a few.
> > 
> > Turning Zaamo off needs a compiler that accepts _zaamo and _zalrsc in
> > -march. GCC 15.1 is the first release that does.
> > TOOLCHAIN_HAS_ZALRSC_ZAAMO checks for it; with an older compiler the
> > option stays at y.
> > 
> > Three sets of extensions provide every atomic Linux needs. "a" is what
> > the kernel supports today. Zalrsc plus Ziccrse is what this patch adds:
> > every atomic is a constrained LR/SC loop, and Ziccrse is the
> > forward-progress guarantee for such loops. Zaamo plus Zacas would do
> > as well, with CAS loops in place of LR/SC as on x86, and is left for
> > whoever has such hardware.
> > 
> > Suggested-by: Chao-ying Fu <chao-ying.fu@globalfoundries.com>
> > Nacked-by: Conor Dooley <conor.dooley@microchip.com>
> > Link: https://lore.kernel.org/linux-riscv/20261106-smock-headband-d6a7d568c228@spud/
> 
> I had a quick glance at this revision, and I think you've at least tried
> to resolve the things I was pointing out. Did I miss something, or why
> have you kept the NAK after having resolved the things that I was
> objecting to?
> 

I searched the maillist for this errata, or workaround or downgrading 'A'
or anything else it's named, found something interesting:

IIUC, Paul has rejected the series, at least call for "hold off on merging them"
see
https://lore.kernel.org/linux-riscv/8afa0702-4d30-86e2-5afb-a7c113a92dec@kernel.org/

and 

https://lore.kernel.org/linux-riscv/6201870b-b50d-f6e2-814b-7a1fdbf064db@kernel.org/

But I'm not sure why the same series is still continuously sent out but
in different titles. I think this series can be ignored until riscv
maintainers agree to downgrade the 'A' to subset of 'A', I.E zalrsc