Re: [PATCH 1/6] lib: Add two-byte cmpxchg emulation function
From: David Laight
Date: Sat Sep 12 2026 - 05:36:42 EST
On Fri, 11 Sep 2026 16:09:16 -0700
"Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> On Fri, Sep 11, 2026 at 11:10:17PM +0100, David Laight wrote:
> > On Fri, 11 Sep 2026 19:25:34 +0000
> > Bradley Morgan <brads@xxxxxxxxxxxxxx> wrote:
> >
> > > cmpxchg_emu_u8() emulates one-byte cmpxchg() in terms of four-byte
> > > cmpxchg() for the architectures lacking native one-byte atomics.
> > > The same architectures also lack native two-byte cmpxchg(), where
> > > such an operation is not supported and either fails to compile via
> > > BUILD_BUG() or fails to link, because the bad pointer sentinels
> > > these architectures declare are never defined.
> > >
> > > Add cmpxchg_emu_u16(), the two-byte sibling. It reads the enclosing
> > > word with READ_ONCE(), splices the two target bytes through a union
> > > and loops on cmpxchg() of the full word until the compare succeeds.
> > > Like cmpxchg_emu_u8() it is fully ordered.
> > >
> > > The Kconfig symbol gating this file is renamed from
> > > ARCH_NEED_CMPXCHG_1_EMU to ARCH_NEED_CMPXCHG_1_2_EMU, as it now
> > > selects both the one-byte and the two-byte emulation.
> > >
> > > Suggested-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> > > Signed-off-by: Bradley Morgan <brads@xxxxxxxxxxxxxx>
> > > ---
> > > arch/Kconfig | 2 +-
> > > arch/arc/Kconfig | 2 +-
> > > arch/arm/Kconfig | 2 +-
> > > arch/csky/Kconfig | 2 +-
> > > arch/sh/Kconfig | 2 +-
> > > arch/xtensa/Kconfig | 2 +-
> > > include/linux/cmpxchg-emu.h | 1 +
> > > lib/Makefile | 2 +-
> > > lib/cmpxchg-emu.c | 35 ++++++++++++++++++++++++++++++++---
> > > 9 files changed, 40 insertions(+), 10 deletions(-)
> > >
> > ...
> > > diff --git a/include/linux/cmpxchg-emu.h b/include/linux/cmpxchg-emu.h
> > > index 998deec67740..fee8171fa05e 100644
> > > --- a/include/linux/cmpxchg-emu.h
> > > +++ b/include/linux/cmpxchg-emu.h
> > > @@ -11,5 +11,6 @@
> > > #define __LINUX_CMPXCHG_EMU_H
> > >
> > > uintptr_t cmpxchg_emu_u8(volatile u8 *p, uintptr_t old, uintptr_t new);
> > > +uintptr_t cmpxchg_emu_u16(volatile u16 *p, uintptr_t old, uintptr_t new);
> >
> > Why uintptr_t? Shouldn't it just be u16?
> > (Which probably means the code would better if it was just 'unsigned int')
>
> I suspect that Bradley is just following my cmpxchg_emu_u8() example,
> which also returns uintptr_t.
>
> I remember that *something* broke when I made this be u8, but I cannot
> recall what the problem was.
>
> Bradley, could you please try making it be u16 as David suggests just to
> see what happens? Who knows? Maybe it was a compiler issue that has
> since been fixed. Or maybe the macros and asms using cmpxchg_emu_u8()
> need that uintptr_t for some reason.
I think the uintptr (unsigned long) cast is needed to stop a compile
error when exchanging pointers.
But that is an issue with the #define not the called functions.
Possibly changing the #define to have:
unsigned long ul_old = (unsigned long)(old);
Or even, with the type check from:
unsigned long ul_old = (unsigned long)(0 ? *(ptr) : (old));
(with the same for 'new')
and the removing all the casts where the value are used might be better.
David
>
> Thanx, Paul