[PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[Bradley Morgan]

This is v5 of the two-byte cmpxchg emulation series, reduced to the
three architectures still missing after Paul McKenney queued the lib
and sh patches, ARC, csky and xtensa.

The v4 attempt at these folded in a type checking idiom,
(unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
to compile. The kernel test robot and Vineet Gupta showed that idiom
breaks real callers, fs/crypto/hooks.c passes a char * and an
unsigned char * to cmpxchg_release(), and the conditional expression
then has incompatible pointer types, which is a hard error on gcc 14
and newer. So this version only adds the case 2 dispatch, the
declarations the architectures already have are kept as is.

The ARC sizeof bug that v4 fixed along the way is in mainline
separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
to use size of pointed type not pointer"), so the ARC patch here is
only the case 2 wiring on top of that.

On the why, RCU previously used single-byte cmpxchg(), which is what
motivated cmpxchg_emu_u8() in the first place, and Paul has now
queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
it into the architectures that need it is the missing half, and
there are existing workarounds for the missing two-byte cmpxchg() in
the tree, _Q_PENDING_BITS for one, that can make use of it.

Per Paul's suggestion each patch is standalone and can go in
independently, they only depend on the lib patch already queued.
Each one was build tested with the real cross toolchain, ARC with
arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
builds Vineet pointed at, W=1, with the macro instantiated on
u8, u16, u32 and pointer types, confirming the new dispatch is
reached and no new warnings appear. The pointer instantiation
covers the fs/crypto/hooks.c case that broke v4.

Bradley Morgan (3):
  ARC: Emulate two-byte cmpxchg
  csky: Emulate two-byte cmpxchg
  xtensa: Emulate two-byte cmpxchg

 arch/arc/include/asm/cmpxchg.h    | 3 +++
 arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
 arch/xtensa/include/asm/cmpxchg.h | 1 +
 3 files changed, 13 insertions(+)

-- 
2.53.0

[PATCH v5 1/3] ARC: Emulate two-byte cmpxchg

[Bradley Morgan]

ARC has no two-byte atomic compare and swap, so the
arch_cmpxchg_relaxed() macro switch lets case 2 fall through to
BUILD_BUG() via default, and a two-byte cmpxchg() fails the build.

Route case 2 through the new cmpxchg_emu_u16(), which narrows the
old and new values itself, so the dispatch keeps the (uintptr_t)
casts the case 1 path already uses.

The sizeof(*(_p_)) fix that v4 folded in here landed separately
through Vineet's f050c3e61d2a, so this patch is now only the
case 2 wiring.

Signed-off-by: Bradley Morgan <brads@mainlining.org>
---
 arch/arc/include/asm/cmpxchg.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
index 66b3743c9400..b30b20933f32 100644
--- a/arch/arc/include/asm/cmpxchg.h
+++ b/arch/arc/include/asm/cmpxchg.h
@@ -50,6 +50,9 @@
 	case 1:								\
 		_prev_ = (__typeof__(*(ptr)))cmpxchg_emu_u8((volatile u8 *__force)_p_, (uintptr_t)_o_, (uintptr_t)_n_);	\
 		break;							\
+	case 2:								\
+		_prev_ = (__typeof__(*(ptr)))cmpxchg_emu_u16((volatile u16 *__force)_p_, (unsigned long)_o_, (unsigned long)_n_);	\
+		break;							\
 	case 4:								\
 		_prev_ = __cmpxchg(_p_, _o_, _n_);			\
 		break;							\
-- 
2.53.0

Re: [PATCH v5 1/3] ARC: Emulate two-byte cmpxchg

[kernel test robot]

Hi Bradley,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on vgupta-arc/for-curr jcmvbkbc-xtensa/xtensa-for-next linus/master v7.3-rc6 next-20261005]
[cannot apply to vgupta-arc/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Bradley-Morgan/ARC-Emulate-two-byte-cmpxchg/20261005-120658
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20261005120700.383058-2-brads%40mainlining.org
patch subject: [PATCH v5 1/3] ARC: Emulate two-byte cmpxchg
config: arc-allyesconfig (https://download.01.org/0day-ci/archive/20261006/202610061706.jjwf7ggl-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261006/202610061706.jjwf7ggl-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202610061706.jjwf7ggl-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/arc/include/asm/atomic.h:13,
                    from include/linux/atomic.h:7,
                    from include/asm-generic/bitops/lock.h:5,
                    from arch/arc/include/asm/bitops.h:190,
                    from include/linux/bitops.h:67,
                    from include/linux/log2.h:12,
                    from kernel/bounds.c:14:
   include/linux/atomic/atomic-arch-fallback.h: In function 'raw_atomic_cmpxchg':
>> arch/arc/include/asm/cmpxchg.h:54:46: error: implicit declaration of function 'cmpxchg_emu_u16'; did you mean 'cmpxchg_emu_u8'? [-Wimplicit-function-declaration]
      54 |                 _prev_ = (__typeof__(*(ptr)))cmpxchg_emu_u16((volatile u16 *__force)_p_, (unsigned long)_o_, (unsigned long)_n_);       \
         |                                              ^~~~~~~~~~~~~~~
   include/linux/atomic.h:73:16: note: in expansion of macro 'arch_cmpxchg_relaxed'
      73 |         typeof(op##_relaxed(args)) __ret;                               \
         |                ^~
   include/linux/atomic/atomic-arch-fallback.h:58:9: note: in expansion of macro '__atomic_op_fence'
      58 |         __atomic_op_fence(arch_cmpxchg, __VA_ARGS__)
         |         ^~~~~~~~~~~~~~~~~
   include/linux/atomic/atomic-arch-fallback.h:2026:16: note: in expansion of macro 'raw_cmpxchg'
    2026 |         return raw_cmpxchg(&v->counter, old, new);
         |                ^~~~~~~~~~~
   make[3]: *** [scripts/Makefile.build:185: kernel/bounds.s] Error 1
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1405: prepare0] Error 2
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:248: __sub-make] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:248: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +54 arch/arc/include/asm/cmpxchg.h

    41	
    42	#define arch_cmpxchg_relaxed(ptr, old, new)				\
    43	({									\
    44		__typeof__(ptr) _p_ = (ptr);					\
    45		__typeof__(*(ptr)) _o_ = (old);					\
    46		__typeof__(*(ptr)) _n_ = (new);					\
    47		__typeof__(*(ptr)) _prev_;					\
    48										\
    49		switch (sizeof(*(_p_))) {						\
    50		case 1:								\
    51			_prev_ = (__typeof__(*(ptr)))cmpxchg_emu_u8((volatile u8 *__force)_p_, (uintptr_t)_o_, (uintptr_t)_n_);	\
    52			break;							\
    53		case 2:								\
  > 54			_prev_ = (__typeof__(*(ptr)))cmpxchg_emu_u16((volatile u16 *__force)_p_, (unsigned long)_o_, (unsigned long)_n_);	\
    55			break;							\
    56		case 4:								\
    57			_prev_ = __cmpxchg(_p_, _o_, _n_);			\
    58			break;							\
    59		default:							\
    60			BUILD_BUG();						\
    61		}								\
    62		_prev_;								\
    63	})
    64	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v5 2/3] csky: Emulate two-byte cmpxchg

[Bradley Morgan]

C-SKY has no two-byte atomic compare and swap, so the __cmpxchg()
macros let case 2 fall through to BUILD_BUG() via default, and a
two-byte cmpxchg() fails the build.

Route case 2 through the new cmpxchg_emu_u16(), which narrows the
old and new values itself, so all three orderings, relaxed, acquire
and full, keep the (uintptr_t) casts the case 1 path already uses.

Signed-off-by: Bradley Morgan <brads@mainlining.org>
---
 arch/csky/include/asm/cmpxchg.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/csky/include/asm/cmpxchg.h b/arch/csky/include/asm/cmpxchg.h
index db6dda47184e..6f3ca79e54ac 100644
--- a/arch/csky/include/asm/cmpxchg.h
+++ b/arch/csky/include/asm/cmpxchg.h
@@ -64,6 +64,9 @@
 	switch (size) {						\
 	case 1:							\
 		__ret = (__typeof__(*(ptr)))cmpxchg_emu_u8((volatile u8 *)__ptr, (uintptr_t)__old, (uintptr_t)__new); \
+		break;							\
+	case 2:							\
+		__ret = (__typeof__(*(ptr)))cmpxchg_emu_u16((volatile u16 *)__ptr, (unsigned long)__old, (unsigned long)__new); \
 		break;						\
 	case 4:							\
 		asm volatile (					\
@@ -97,6 +100,9 @@
 	switch (size) {						\
 	case 1:							\
 		__ret = (__typeof__(*(ptr)))cmpxchg_emu_u8((volatile u8 *)__ptr, (uintptr_t)__old, (uintptr_t)__new); \
+		break;							\
+	case 2:							\
+		__ret = (__typeof__(*(ptr)))cmpxchg_emu_u16((volatile u16 *)__ptr, (unsigned long)__old, (unsigned long)__new); \
 		break;						\
 	case 4:							\
 		asm volatile (					\
@@ -131,6 +137,9 @@
 	switch (size) {						\
 	case 1:							\
 		__ret = (__typeof__(*(ptr)))cmpxchg_emu_u8((volatile u8 *)__ptr, (uintptr_t)__old, (uintptr_t)__new); \
+		break;							\
+	case 2:							\
+		__ret = (__typeof__(*(ptr)))cmpxchg_emu_u16((volatile u16 *)__ptr, (unsigned long)__old, (unsigned long)__new); \
 		break;						\
 	case 4:							\
 		asm volatile (					\
-- 
2.53.0

[PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Bradley Morgan]

Xtensa has no two-byte atomic compare and swap, so the __cmpxchg()
switch lets case 2 fall through to __cmpxchg_called_with_bad_pointer(),
which is declared but never defined, so a two-byte cmpxchg() fails
at link time.

Route case 2 through the new cmpxchg_emu_u16(), which takes the
old and new values as unsigned long and narrows them itself, so
the call needs no extra casts.

Signed-off-by: Bradley Morgan <brads@mainlining.org>
---
 arch/xtensa/include/asm/cmpxchg.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/xtensa/include/asm/cmpxchg.h b/arch/xtensa/include/asm/cmpxchg.h
index b6db4838b175..8dea8e357fc0 100644
--- a/arch/xtensa/include/asm/cmpxchg.h
+++ b/arch/xtensa/include/asm/cmpxchg.h
@@ -76,6 +76,7 @@ __cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
 {
 	switch (size) {
 	case 1:  return cmpxchg_emu_u8(ptr, old, new);
+	case 2:  return cmpxchg_emu_u16(ptr, old, new);
 	case 4:  return __cmpxchg_u32(ptr, old, new);
 	default: __cmpxchg_called_with_bad_pointer();
 		 return old;
-- 
2.53.0

Re: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[kernel test robot]

Hi Bradley,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on vgupta-arc/for-curr jcmvbkbc-xtensa/xtensa-for-next linus/master v7.3-rc6 next-20261005]
[cannot apply to vgupta-arc/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Bradley-Morgan/ARC-Emulate-two-byte-cmpxchg/20261005-120658
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20261005120700.383058-4-brads%40mainlining.org
patch subject: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg
config: xtensa-allyesconfig (https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/config)
compiler: xtensa-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202610061704.rvbolgPy-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/xtensa/include/asm/atomic.h:19,
                    from include/linux/atomic.h:7,
                    from include/asm-generic/bitops/atomic.h:5,
                    from arch/xtensa/include/asm/bitops.h:192,
                    from include/linux/bitops.h:67,
                    from include/linux/log2.h:12,
                    from kernel/bounds.c:14:
   arch/xtensa/include/asm/cmpxchg.h: In function '__cmpxchg':
>> arch/xtensa/include/asm/cmpxchg.h:79:25: error: implicit declaration of function 'cmpxchg_emu_u16'; did you mean 'cmpxchg_emu_u8'? [-Wimplicit-function-declaration]
      79 |         case 2:  return cmpxchg_emu_u16(ptr, old, new);
         |                         ^~~~~~~~~~~~~~~
         |                         cmpxchg_emu_u8
   make[3]: *** [scripts/Makefile.build:185: kernel/bounds.s] Error 1
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1405: prepare0] Error 2
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:248: __sub-make] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:248: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +79 arch/xtensa/include/asm/cmpxchg.h

    73	
    74	static __inline__ unsigned long
    75	__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
    76	{
    77		switch (size) {
    78		case 1:  return cmpxchg_emu_u8(ptr, old, new);
  > 79		case 2:  return cmpxchg_emu_u16(ptr, old, new);
    80		case 4:  return __cmpxchg_u32(ptr, old, new);
    81		default: __cmpxchg_called_with_bad_pointer();
    82			 return old;
    83		}
    84	}
    85	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Paul E. McKenney]

On Tue, Oct 06, 2026 at 05:54:53PM +0800, kernel test robot wrote:
> Hi Bradley,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on akpm-mm/mm-everything]
> [also build test ERROR on vgupta-arc/for-curr jcmvbkbc-xtensa/xtensa-for-next linus/master v7.3-rc6 next-20261005]
> [cannot apply to vgupta-arc/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Bradley-Morgan/ARC-Emulate-two-byte-cmpxchg/20261005-120658
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link:    https://lore.kernel.org/r/20261005120700.383058-4-brads%40mainlining.org
> patch subject: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg
> config: xtensa-allyesconfig (https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/config)
> compiler: xtensa-linux-gcc (GCC) 16.1.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202610061704.rvbolgPy-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):

These patches need to be applied on top of my -rcu tree's "dev" branch,
which supplies cmpxchg_emu_u16().

Nevertheless, thank you for your testing efforts!

							Thanx, Paul

>    In file included from arch/xtensa/include/asm/atomic.h:19,
>                     from include/linux/atomic.h:7,
>                     from include/asm-generic/bitops/atomic.h:5,
>                     from arch/xtensa/include/asm/bitops.h:192,
>                     from include/linux/bitops.h:67,
>                     from include/linux/log2.h:12,
>                     from kernel/bounds.c:14:
>    arch/xtensa/include/asm/cmpxchg.h: In function '__cmpxchg':
> >> arch/xtensa/include/asm/cmpxchg.h:79:25: error: implicit declaration of function 'cmpxchg_emu_u16'; did you mean 'cmpxchg_emu_u8'? [-Wimplicit-function-declaration]
>       79 |         case 2:  return cmpxchg_emu_u16(ptr, old, new);
>          |                         ^~~~~~~~~~~~~~~
>          |                         cmpxchg_emu_u8
>    make[3]: *** [scripts/Makefile.build:185: kernel/bounds.s] Error 1
>    make[3]: Target 'prepare' not remade because of errors.
>    make[2]: *** [Makefile:1405: prepare0] Error 2
>    make[2]: Target 'prepare' not remade because of errors.
>    make[1]: *** [Makefile:248: __sub-make] Error 2
>    make[1]: Target 'prepare' not remade because of errors.
>    make: *** [Makefile:248: __sub-make] Error 2
>    make: Target 'prepare' not remade because of errors.
> 
> 
> vim +79 arch/xtensa/include/asm/cmpxchg.h
> 
>     73	
>     74	static __inline__ unsigned long
>     75	__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
>     76	{
>     77		switch (size) {
>     78		case 1:  return cmpxchg_emu_u8(ptr, old, new);
>   > 79		case 2:  return cmpxchg_emu_u16(ptr, old, new);
>     80		case 4:  return __cmpxchg_u32(ptr, old, new);
>     81		default: __cmpxchg_called_with_bad_pointer();
>     82			 return old;
>     83		}
>     84	}
>     85	
> 
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki

Re: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Bradley Morgan]

On 6 October 2026 16:44:13 BST, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Tue, Oct 06, 2026 at 05:54:53PM +0800, kernel test robot wrote:
>> Hi Bradley,
>> 
>> kernel test robot noticed the following build errors:
>> 
>> [auto build test ERROR on akpm-mm/mm-everything]
>> [also build test ERROR on vgupta-arc/for-curr
>jcmvbkbc-xtensa/xtensa-for-next linus/master v7.3-rc6 next-20261005]
>> [cannot apply to vgupta-arc/for-next]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>> 
>> url:   
>https://github.com/intel-lab-lkp/linux/commits/Bradley-Morgan/ARC-Emulate-two-byte-cmpxchg/20261005-120658
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
>mm-everything
>> patch link:   
>https://lore.kernel.org/r/20261005120700.383058-4-brads%40mainlining.org
>> patch subject: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg
>> config: xtensa-allyesconfig
>(https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/config)
>> compiler: xtensa-linux-gcc (GCC) 16.1.0
>> reproduce (this is a W=1 build):
>(https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/reproduce)
>> 
>> If you fix the issue in a separate patch/commit (i.e. not just a new
>version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes:
>https://lore.kernel.org/oe-kbuild-all/202610061704.rvbolgPy-lkp@intel.com/
>> 
>> All errors (new ones prefixed by >>):
>
>These patches need to be applied on top of my -rcu tree's "dev" branch,
>which supplies cmpxchg_emu_u16().
>
>Nevertheless, thank you for your testing efforts!

Do you reckon they are fine to you? The patches?

Arch maintainers may be busy unfortunately :(, I've done testing on all
the arches, 

>
>							Thanx, Paul
>
>>    In file included from arch/xtensa/include/asm/atomic.h:19,
>>                     from include/linux/atomic.h:7,
>>                     from include/asm-generic/bitops/atomic.h:5,
>>                     from arch/xtensa/include/asm/bitops.h:192,
>>                     from include/linux/bitops.h:67,
>>                     from include/linux/log2.h:12,
>>                     from kernel/bounds.c:14:
>>    arch/xtensa/include/asm/cmpxchg.h: In function '__cmpxchg':
>> >> arch/xtensa/include/asm/cmpxchg.h:79:25: error: implicit declaration
>of function 'cmpxchg_emu_u16'; did you mean 'cmpxchg_emu_u8'?
>[-Wimplicit-function-declaration]
>>       79 |         case 2:  return cmpxchg_emu_u16(ptr, old, new);
>>          |                         ^~~~~~~~~~~~~~~
>>          |                         cmpxchg_emu_u8
>>    make[3]: *** [scripts/Makefile.build:185: kernel/bounds.s] Error 1
>>    make[3]: Target 'prepare' not remade because of errors.
>>    make[2]: *** [Makefile:1405: prepare0] Error 2
>>    make[2]: Target 'prepare' not remade because of errors.
>>    make[1]: *** [Makefile:248: __sub-make] Error 2
>>    make[1]: Target 'prepare' not remade because of errors.
>>    make: *** [Makefile:248: __sub-make] Error 2
>>    make: Target 'prepare' not remade because of errors.
>> 
>> 
>> vim +79 arch/xtensa/include/asm/cmpxchg.h
>> 
>>     73	
>>     74	static __inline__ unsigned long
>>     75	__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
>>     76	{
>>     77		switch (size) {
>>     78		case 1:  return cmpxchg_emu_u8(ptr, old, new);
>>   > 79		case 2:  return cmpxchg_emu_u16(ptr, old, new);
>>     80		case 4:  return __cmpxchg_u32(ptr, old, new);
>>     81		default: __cmpxchg_called_with_bad_pointer();
>>     82			 return old;
>>     83		}
>>     84	}
>>     85	
>> 
>> --
>> 0-DAY CI Kernel Test Service
>> https://github.com/intel/lkp-tests/wiki

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Paul E. McKenney]

On Tue, Oct 06, 2026 at 04:46:22PM +0100, Bradley Morgan wrote:
> On 6 October 2026 16:44:13 BST, "Paul E. McKenney" <paulmck@kernel.org>
> wrote:
> >On Tue, Oct 06, 2026 at 05:54:53PM +0800, kernel test robot wrote:
> >> Hi Bradley,
> >> 
> >> kernel test robot noticed the following build errors:
> >> 
> >> [auto build test ERROR on akpm-mm/mm-everything]
> >> [also build test ERROR on vgupta-arc/for-curr
> >jcmvbkbc-xtensa/xtensa-for-next linus/master v7.3-rc6 next-20261005]
> >> [cannot apply to vgupta-arc/for-next]
> >> [If your patch is applied to the wrong git tree, kindly drop us a note.
> >> And when submitting patch, we suggest to use '--base' as documented in
> >> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >> 
> >> url:   
> >https://github.com/intel-lab-lkp/linux/commits/Bradley-Morgan/ARC-Emulate-two-byte-cmpxchg/20261005-120658
> >> base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
> >mm-everything
> >> patch link:   
> >https://lore.kernel.org/r/20261005120700.383058-4-brads%40mainlining.org
> >> patch subject: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg
> >> config: xtensa-allyesconfig
> >(https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/config)
> >> compiler: xtensa-linux-gcc (GCC) 16.1.0
> >> reproduce (this is a W=1 build):
> >(https://download.01.org/0day-ci/archive/20261006/202610061704.rvbolgPy-lkp@intel.com/reproduce)
> >> 
> >> If you fix the issue in a separate patch/commit (i.e. not just a new
> >version of
> >> the same patch/commit), kindly add following tags
> >> | Reported-by: kernel test robot <lkp@intel.com>
> >> | Closes:
> >https://lore.kernel.org/oe-kbuild-all/202610061704.rvbolgPy-lkp@intel.com/
> >> 
> >> All errors (new ones prefixed by >>):
> >
> >These patches need to be applied on top of my -rcu tree's "dev" branch,
> >which supplies cmpxchg_emu_u16().
> >
> >Nevertheless, thank you for your testing efforts!
> 
> Do you reckon they are fine to you? The patches?
> 
> Arch maintainers may be busy unfortunately :(, I've done testing on all
> the arches, 

I have queued the one that is already acked by the SH maintainer, so we
get at least something into the upcoming merge window.  I plan to try your
patches out later today, Pacific Time, and queue them if they are ready.

If the architecture maintainers ack them in time, I send a pull request
for them in the upcoming merge window.  If some of the do not yet have
acks, I keep those unacked ones for the next merge window.  If they
are still being ignored at that point, I send the pull request anyway.
Maybe Linus takes it, maybe not.  If not, I figure things out from that
point.

Hey, it is a lot faster than some other communities that I am involved
with, where the timeframes are years and even decades rather than
mere weeks and months.  ;-)

							Thanx, Paul

> >>    In file included from arch/xtensa/include/asm/atomic.h:19,
> >>                     from include/linux/atomic.h:7,
> >>                     from include/asm-generic/bitops/atomic.h:5,
> >>                     from arch/xtensa/include/asm/bitops.h:192,
> >>                     from include/linux/bitops.h:67,
> >>                     from include/linux/log2.h:12,
> >>                     from kernel/bounds.c:14:
> >>    arch/xtensa/include/asm/cmpxchg.h: In function '__cmpxchg':
> >> >> arch/xtensa/include/asm/cmpxchg.h:79:25: error: implicit declaration
> >of function 'cmpxchg_emu_u16'; did you mean 'cmpxchg_emu_u8'?
> >[-Wimplicit-function-declaration]
> >>       79 |         case 2:  return cmpxchg_emu_u16(ptr, old, new);
> >>          |                         ^~~~~~~~~~~~~~~
> >>          |                         cmpxchg_emu_u8
> >>    make[3]: *** [scripts/Makefile.build:185: kernel/bounds.s] Error 1
> >>    make[3]: Target 'prepare' not remade because of errors.
> >>    make[2]: *** [Makefile:1405: prepare0] Error 2
> >>    make[2]: Target 'prepare' not remade because of errors.
> >>    make[1]: *** [Makefile:248: __sub-make] Error 2
> >>    make[1]: Target 'prepare' not remade because of errors.
> >>    make: *** [Makefile:248: __sub-make] Error 2
> >>    make: Target 'prepare' not remade because of errors.
> >> 
> >> 
> >> vim +79 arch/xtensa/include/asm/cmpxchg.h
> >> 
> >>     73	
> >>     74	static __inline__ unsigned long
> >>     75	__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
> >>     76	{
> >>     77		switch (size) {
> >>     78		case 1:  return cmpxchg_emu_u8(ptr, old, new);
> >>   > 79		case 2:  return cmpxchg_emu_u16(ptr, old, new);
> >>     80		case 4:  return __cmpxchg_u32(ptr, old, new);
> >>     81		default: __cmpxchg_called_with_bad_pointer();
> >>     82			 return old;
> >>     83		}
> >>     84	}
> >>     85	
> >> 
> >> --
> >> 0-DAY CI Kernel Test Service
> >> https://github.com/intel/lkp-tests/wiki
> 
> --- Thanks!
> "I'm not a very positive person" - Linus torvalds

Re: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Vineet Gupta]

On 10/6/26 17:46, Bradley Morgan wrote:
> Do you reckon they are fine to you? The patches?
>
> Arch maintainers may be busy unfortunately 🙁, I've done testing on all
> the arches,

Everyone is traveling due to the conf season - LPC, ELC.

-Vineet

Re: [PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Vineet Gupta]

On 10/6/26 17:44, Paul E. McKenney wrote:
> These patches need to be applied on top of my -rcu tree's "dev" branch,
> which supplies cmpxchg_emu_u16().
>
> Nevertheless, thank you for your testing efforts!

Sorry I don't have your tree is my git remotes. can u point me to the 
msg id of the series which was applied so i can fetch it and apply.
At this point I can't ACK/Nack the patch since w/o the pre-req it just 
fails to build locally exactly as the kernel robot found.

Thx,
-Vineet

Re: [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[Bradley Morgan]

On 5 October 2026 13:06:57 BST, Bradley Morgan <brads@mainlining.org>
wrote:
>This is v5 of the two-byte cmpxchg emulation series, reduced to the
>three architectures still missing after Paul McKenney queued the lib
>and sh patches, ARC, csky and xtensa.
>
>The v4 attempt at these folded in a type checking idiom,
>(unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
>to compile. The kernel test robot and Vineet Gupta showed that idiom
>breaks real callers, fs/crypto/hooks.c passes a char * and an
>unsigned char * to cmpxchg_release(), and the conditional expression
>then has incompatible pointer types, which is a hard error on gcc 14
>and newer. So this version only adds the case 2 dispatch, the
>declarations the architectures already have are kept as is.
>
>The ARC sizeof bug that v4 fixed along the way is in mainline
>separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
>to use size of pointed type not pointer"), so the ARC patch here is
>only the case 2 wiring on top of that.

Sashiko took a hitch at it, all the "bugs" are bogus, most are just cuz
"u16 is undefined oh no error", but they didn't see Paul's tree, where it
is defined.

whatever

>
>On the why, RCU previously used single-byte cmpxchg(), which is what
>motivated cmpxchg_emu_u8() in the first place, and Paul has now
>queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
>it into the architectures that need it is the missing half, and
>there are existing workarounds for the missing two-byte cmpxchg() in
>the tree, _Q_PENDING_BITS for one, that can make use of it.
>
>Per Paul's suggestion each patch is standalone and can go in
>independently, they only depend on the lib patch already queued.
>Each one was build tested with the real cross toolchain, ARC with
>arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
>builds Vineet pointed at, W=1, with the macro instantiated on
>u8, u16, u32 and pointer types, confirming the new dispatch is
>reached and no new warnings appear. The pointer instantiation
>covers the fs/crypto/hooks.c case that broke v4.
>
>Bradley Morgan (3):
>  ARC: Emulate two-byte cmpxchg
>  csky: Emulate two-byte cmpxchg
>  xtensa: Emulate two-byte cmpxchg
>
> arch/arc/include/asm/cmpxchg.h    | 3 +++
> arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
> arch/xtensa/include/asm/cmpxchg.h | 1 +
> 3 files changed, 13 insertions(+)
>
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[David Laight]

On Mon,  5 Oct 2026 12:06:57 +0000
Bradley Morgan <brads@mainlining.org> wrote:

> This is v5 of the two-byte cmpxchg emulation series, reduced to the
> three architectures still missing after Paul McKenney queued the lib
> and sh patches, ARC, csky and xtensa.
> 
> The v4 attempt at these folded in a type checking idiom,
> (unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
> to compile. The kernel test robot and Vineet Gupta showed that idiom
> breaks real callers, fs/crypto/hooks.c passes a char * and an
> unsigned char * to cmpxchg_release(),

That ought to be a bug...

David

> and the conditional expression
> then has incompatible pointer types, which is a hard error on gcc 14
> and newer. So this version only adds the case 2 dispatch, the
> declarations the architectures already have are kept as is.
> 
> The ARC sizeof bug that v4 fixed along the way is in mainline
> separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
> to use size of pointed type not pointer"), so the ARC patch here is
> only the case 2 wiring on top of that.
> 
> On the why, RCU previously used single-byte cmpxchg(), which is what
> motivated cmpxchg_emu_u8() in the first place, and Paul has now
> queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
> it into the architectures that need it is the missing half, and
> there are existing workarounds for the missing two-byte cmpxchg() in
> the tree, _Q_PENDING_BITS for one, that can make use of it.
> 
> Per Paul's suggestion each patch is standalone and can go in
> independently, they only depend on the lib patch already queued.
> Each one was build tested with the real cross toolchain, ARC with
> arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
> builds Vineet pointed at, W=1, with the macro instantiated on
> u8, u16, u32 and pointer types, confirming the new dispatch is
> reached and no new warnings appear. The pointer instantiation
> covers the fs/crypto/hooks.c case that broke v4.
> 
> Bradley Morgan (3):
>   ARC: Emulate two-byte cmpxchg
>   csky: Emulate two-byte cmpxchg
>   xtensa: Emulate two-byte cmpxchg
> 
>  arch/arc/include/asm/cmpxchg.h    | 3 +++
>  arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
>  arch/xtensa/include/asm/cmpxchg.h | 1 +
>  3 files changed, 13 insertions(+)
> 

Re: [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[Paul E. McKenney]

On Mon, Oct 05, 2026 at 07:02:05PM +0100, David Laight wrote:
> On Mon,  5 Oct 2026 12:06:57 +0000
> Bradley Morgan <brads@mainlining.org> wrote:
> 
> > This is v5 of the two-byte cmpxchg emulation series, reduced to the
> > three architectures still missing after Paul McKenney queued the lib
> > and sh patches, ARC, csky and xtensa.
> > 
> > The v4 attempt at these folded in a type checking idiom,
> > (unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
> > to compile. The kernel test robot and Vineet Gupta showed that idiom
> > breaks real callers, fs/crypto/hooks.c passes a char * and an
> > unsigned char * to cmpxchg_release(),
> 
> That ought to be a bug...

Perhaps it is?  Here is the code:

	cmpxchg_release(&inode->i_link, NULL, pstr.name)

And inode is a struct inode, of which ->i_link is char*.  For its part,
pstr is a struct fscrypt_str, of which ->name is unsigned char *.

But this is either a 4-byte or 8-byte cmpxchg_release(), depending on
CONFIG_64BIT, which is orthogonal to this patch series, which provides
2-byte emulation.

Therefore, I see no reason to hold up these cmpxchg_emu_u16() patches.

But please let me know if I am missing something.

							Thanx, Paul

> David
> 
> > and the conditional expression
> > then has incompatible pointer types, which is a hard error on gcc 14
> > and newer. So this version only adds the case 2 dispatch, the
> > declarations the architectures already have are kept as is.
> > 
> > The ARC sizeof bug that v4 fixed along the way is in mainline
> > separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
> > to use size of pointed type not pointer"), so the ARC patch here is
> > only the case 2 wiring on top of that.
> > 
> > On the why, RCU previously used single-byte cmpxchg(), which is what
> > motivated cmpxchg_emu_u8() in the first place, and Paul has now
> > queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
> > it into the architectures that need it is the missing half, and
> > there are existing workarounds for the missing two-byte cmpxchg() in
> > the tree, _Q_PENDING_BITS for one, that can make use of it.
> > 
> > Per Paul's suggestion each patch is standalone and can go in
> > independently, they only depend on the lib patch already queued.
> > Each one was build tested with the real cross toolchain, ARC with
> > arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
> > builds Vineet pointed at, W=1, with the macro instantiated on
> > u8, u16, u32 and pointer types, confirming the new dispatch is
> > reached and no new warnings appear. The pointer instantiation
> > covers the fs/crypto/hooks.c case that broke v4.
> > 
> > Bradley Morgan (3):
> >   ARC: Emulate two-byte cmpxchg
> >   csky: Emulate two-byte cmpxchg
> >   xtensa: Emulate two-byte cmpxchg
> > 
> >  arch/arc/include/asm/cmpxchg.h    | 3 +++
> >  arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
> >  arch/xtensa/include/asm/cmpxchg.h | 1 +
> >  3 files changed, 13 insertions(+)
> > 
> 

Re: [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[David Laight]

On Tue, 6 Oct 2026 11:16:42 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> On Mon, Oct 05, 2026 at 07:02:05PM +0100, David Laight wrote:
> > On Mon,  5 Oct 2026 12:06:57 +0000
> > Bradley Morgan <brads@mainlining.org> wrote:
> >   
> > > This is v5 of the two-byte cmpxchg emulation series, reduced to the
> > > three architectures still missing after Paul McKenney queued the lib
> > > and sh patches, ARC, csky and xtensa.
> > > 
> > > The v4 attempt at these folded in a type checking idiom,
> > > (unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
> > > to compile. The kernel test robot and Vineet Gupta showed that idiom
> > > breaks real callers, fs/crypto/hooks.c passes a char * and an
> > > unsigned char * to cmpxchg_release(),  
> > 
> > That ought to be a bug...  
> 
> Perhaps it is?  Here is the code:
> 
> 	cmpxchg_release(&inode->i_link, NULL, pstr.name)
> 
> And inode is a struct inode, of which ->i_link is char*.  For its part,
> pstr is a struct fscrypt_str, of which ->name is unsigned char *.
> 
> But this is either a 4-byte or 8-byte cmpxchg_release(), depending on
> CONFIG_64BIT, which is orthogonal to this patch series, which provides
> 2-byte emulation.
> 
> Therefore, I see no reason to hold up these cmpxchg_emu_u16() patches.

True.

David

> 
> But please let me know if I am missing something.
> 
> 							Thanx, Paul
> 
> > David
> >   
> > > and the conditional expression
> > > then has incompatible pointer types, which is a hard error on gcc 14
> > > and newer. So this version only adds the case 2 dispatch, the
> > > declarations the architectures already have are kept as is.
> > > 
> > > The ARC sizeof bug that v4 fixed along the way is in mainline
> > > separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
> > > to use size of pointed type not pointer"), so the ARC patch here is
> > > only the case 2 wiring on top of that.
> > > 
> > > On the why, RCU previously used single-byte cmpxchg(), which is what
> > > motivated cmpxchg_emu_u8() in the first place, and Paul has now
> > > queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
> > > it into the architectures that need it is the missing half, and
> > > there are existing workarounds for the missing two-byte cmpxchg() in
> > > the tree, _Q_PENDING_BITS for one, that can make use of it.
> > > 
> > > Per Paul's suggestion each patch is standalone and can go in
> > > independently, they only depend on the lib patch already queued.
> > > Each one was build tested with the real cross toolchain, ARC with
> > > arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
> > > builds Vineet pointed at, W=1, with the macro instantiated on
> > > u8, u16, u32 and pointer types, confirming the new dispatch is
> > > reached and no new warnings appear. The pointer instantiation
> > > covers the fs/crypto/hooks.c case that broke v4.
> > > 
> > > Bradley Morgan (3):
> > >   ARC: Emulate two-byte cmpxchg
> > >   csky: Emulate two-byte cmpxchg
> > >   xtensa: Emulate two-byte cmpxchg
> > > 
> > >  arch/arc/include/asm/cmpxchg.h    | 3 +++
> > >  arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
> > >  arch/xtensa/include/asm/cmpxchg.h | 1 +
> > >  3 files changed, 13 insertions(+)
> > >   
> >   

Re: [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[Paul E. McKenney]

On Mon, Oct 05, 2026 at 12:06:57PM +0000, Bradley Morgan wrote:
> This is v5 of the two-byte cmpxchg emulation series, reduced to the
> three architectures still missing after Paul McKenney queued the lib
> and sh patches, ARC, csky and xtensa.
> 
> The v4 attempt at these folded in a type checking idiom,
> (unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
> to compile. The kernel test robot and Vineet Gupta showed that idiom
> breaks real callers, fs/crypto/hooks.c passes a char * and an
> unsigned char * to cmpxchg_release(), and the conditional expression
> then has incompatible pointer types, which is a hard error on gcc 14
> and newer. So this version only adds the case 2 dispatch, the
> declarations the architectures already have are kept as is.
> 
> The ARC sizeof bug that v4 fixed along the way is in mainline
> separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
> to use size of pointed type not pointer"), so the ARC patch here is
> only the case 2 wiring on top of that.
> 
> On the why, RCU previously used single-byte cmpxchg(), which is what
> motivated cmpxchg_emu_u8() in the first place, and Paul has now
> queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
> it into the architectures that need it is the missing half, and
> there are existing workarounds for the missing two-byte cmpxchg() in
> the tree, _Q_PENDING_BITS for one, that can make use of it.
> 
> Per Paul's suggestion each patch is standalone and can go in
> independently, they only depend on the lib patch already queued.
> Each one was build tested with the real cross toolchain, ARC with
> arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
> builds Vineet pointed at, W=1, with the macro instantiated on
> u8, u16, u32 and pointer types, confirming the new dispatch is
> reached and no new warnings appear. The pointer instantiation
> covers the fs/crypto/hooks.c case that broke v4.

Queued for review and testing, thank you!

							Thanx, Paul

> Bradley Morgan (3):
>   ARC: Emulate two-byte cmpxchg
>   csky: Emulate two-byte cmpxchg
>   xtensa: Emulate two-byte cmpxchg
> 
>  arch/arc/include/asm/cmpxchg.h    | 3 +++
>  arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
>  arch/xtensa/include/asm/cmpxchg.h | 1 +
>  3 files changed, 13 insertions(+)
> 
> -- 
> 2.53.0

[PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures

[Bradley Morgan]

This is v5 of the two-byte cmpxchg emulation series, reduced to the
three architectures still missing after Paul McKenney queued the lib
and sh patches, ARC, csky and xtensa.

The v4 attempt at these folded in a type checking idiom,
(unsigned long)(0 ? *ptr : old), meant to make cmpxchg(&p, 4, 5) fail
to compile. The kernel test robot and Vineet Gupta showed that idiom
breaks real callers, fs/crypto/hooks.c passes a char * and an
unsigned char * to cmpxchg_release(), and the conditional expression
then has incompatible pointer types, which is a hard error on gcc 14
and newer. So this version only adds the case 2 dispatch, the
declarations the architectures already have are kept as is.

The ARC sizeof bug that v4 fixed along the way is in mainline
separately through Vineet's f050c3e61d2a ("ARC: arch_cmpxchg_relaxed
to use size of pointed type not pointer"), so the ARC patch here is
only the case 2 wiring on top of that.

On the why, RCU previously used single-byte cmpxchg(), which is what
motivated cmpxchg_emu_u8() in the first place, and Paul has now
queued cmpxchg_emu_u16(). Unused new code is frowned upon, so wiring
it into the architectures that need it is the missing half, and
there are existing workarounds for the missing two-byte cmpxchg() in
the tree, _Q_PENDING_BITS for one, that can make use of it.

Per Paul's suggestion each patch is standalone and can go in
independently, they only depend on the lib patch already queued.
Each one was build tested with the real cross toolchain, ARC with
arc-linux-gnu-gcc and csky and xtensa with the gcc 16.2 crosstool
builds Vineet pointed at, W=1, with the macro instantiated on
u8, u16, u32 and pointer types, confirming the new dispatch is
reached and no new warnings appear. The pointer instantiation
covers the fs/crypto/hooks.c case that broke v4.

Bradley Morgan (3):
  ARC: Emulate two-byte cmpxchg
  csky: Emulate two-byte cmpxchg
  xtensa: Emulate two-byte cmpxchg

 arch/arc/include/asm/cmpxchg.h    | 3 +++
 arch/csky/include/asm/cmpxchg.h   | 9 +++++++++
 arch/xtensa/include/asm/cmpxchg.h | 1 +
 3 files changed, 13 insertions(+)

-- 
2.53.0

[PATCH v5 3/3] xtensa: Emulate two-byte cmpxchg

[Bradley Morgan]

Xtensa has no two-byte atomic compare and swap, so the __cmpxchg()
switch lets case 2 fall through to __cmpxchg_called_with_bad_pointer(),
which is declared but never defined, so a two-byte cmpxchg() fails
at link time.

Route case 2 through the new cmpxchg_emu_u16(), which takes the
old and new values as unsigned long and narrows them itself, so
the call needs no extra casts.

Signed-off-by: Bradley Morgan <brads@mainlining.org>
---
 arch/xtensa/include/asm/cmpxchg.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/xtensa/include/asm/cmpxchg.h b/arch/xtensa/include/asm/cmpxchg.h
index b6db4838b175..8dea8e357fc0 100644
--- a/arch/xtensa/include/asm/cmpxchg.h
+++ b/arch/xtensa/include/asm/cmpxchg.h
@@ -76,6 +76,7 @@ __cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
 {
 	switch (size) {
 	case 1:  return cmpxchg_emu_u8(ptr, old, new);
+	case 2:  return cmpxchg_emu_u16(ptr, old, new);
 	case 4:  return __cmpxchg_u32(ptr, old, new);
 	default: __cmpxchg_called_with_bad_pointer();
 		 return old;
-- 
2.53.0