Re: [PATCH 1/6] lib: Add two-byte cmpxchg emulation function

From: Bradley Morgan

Date: Sat Sep 12 2026 - 06:36:18 EST


On 12 September 2026 10:30:47 BST, David Laight
<david.laight.linux@xxxxxxxxx> wrote:
>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
>
>
Hmm. Okie dokie, noted for V2, thanks for the review,

I'm sure arch code is just implementing this function, so I hope nothing
went wrong with the arch code.
--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@xxxxxxxxx/