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

[Bradley Morgan]

On 11 September 2026 23:10:17 BST, David Laight
<david.laight.linux@xxxxxxxxx> 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?

Hi, Paul suggested I make it as identical as possible to u8, Do you reckon
this would break anything?


>(Which probably means the code would better if it was just 'unsigned int')

Ehh, subjective.

>
>David
>
>

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@xxxxxxxxx/