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

[Bradley Morgan <brads@mainlining.org>]

On 12 September 2026 19:58:02 BST, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Sat, Sep 12, 2026 at 10:30:47AM +0100, David Laight wrote:
>> On Fri, 11 Sep 2026 16:09:16 -0700
>> "Paul E. McKenney" <paulmck@kernel.org> 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@mainlining.org> 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@kernel.org>
>> > > > Signed-off-by: Bradley Morgan <brads@mainlining.org>
>> > > > ---
>> > > >  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.
>
>It does sound worth a try, especially since we have the uintptr_t version
>to fall back on should that fail, or in case it somehow makes things
>more complicated.
>
>But we have been living with uintptr_t for some years with the 8-bit
>code, so this should be able to be a follow-on patch.
>
>							Thanx, Paul
I'll try u16 and then add another patch tryna fix the issue.
--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/