Re: [GIT PULL] Add two-byte cmpxchg emulation function for v7.4

From: David Laight

Date: Mon Nov 02 2026 - 12:58:46 EST


On Mon, 2 Nov 2026 13:21:04 +0100 (CET)
Jan Engelhardt <ej@xxxxxxx> wrote:

> On Friday 2026-10-23 18:12, Paul E. McKenney wrote:
> >> >
> >> >Add emulation of two-byte cmpxchg()
> >> >
> >> >These commits add a cmpxchg_emu_u16() function that emulates two-byte
> >> >cmpxchg() in terms of four-byte cmpxchg() [...]
> >> >namely sh, arc, csky, and xtensa.
> >> >
> >> >There is reason to believe that these systems will soon no longer be
> >> >supported by Linux.
> >>
> >> riscv64 also only has two exchange operations
> >> (lr.w.aqrl/lr.d.aqrl/sc.w.rl/sc.d.rl).
> >> (atomic_compare_exchange_strong with uint8/16_t, in userspace, gets
> >> replaced by the compiler to a lot more instructions thanks to
> >> implied -finline-atomics.)
> >>
> >> Are you saying riscv64 is going to go unsupported too? ;-)
> >
> >Given that the compiler can make it work in userspace, then the riscv64
> >architecture-specific code should be able to make it work in the Linux
> >kernel. At which point there is absolutely no reason that Linux-kernel
> >support for riscv64 should be dropped.
> >
> >Or am I missing something here?
>
> I can get gcc-17.0.0-20261102 with no further command line options
> to turn `atomic_compare_exchange_strong`+uint16 into some object code
> that does not contain a call to libatomic, for sh2, sh3, sh4. Haven't
> tried xtensa or the others.
> Thus, is the patch really needed?
>

Won't that need a big jump in the minimum supported compiler version?
Probably less of a problem than x86 since I guess cross compiles are
a lot more common?

David