mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures
@ 2026-10-05 12:05 Bradley Morgan
  2026-10-05 12:05 ` [PATCH v5 1/3] ARC: Emulate two-byte cmpxchg Bradley Morgan
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Bradley Morgan @ 2026-10-05 12:05 UTC (permalink / raw)
  To: akpm, vgupta, guoren, chris, jcmvbkbc
  Cc: arnd, paulmck, david.laight.linux, glaubitz, ysato, dalias,
	linux-snps-arc, linux-csky, linux-kernel, brads

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


^ permalink raw reply	[flat|nested] 6+ messages in thread
* [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures
@ 2026-10-05 12:06 Bradley Morgan
  2026-10-05 12:06 ` [PATCH v5 1/3] ARC: Emulate two-byte cmpxchg Bradley Morgan
  0 siblings, 1 reply; 6+ messages in thread
From: Bradley Morgan @ 2026-10-05 12:06 UTC (permalink / raw)
  To: akpm, vgupta, guoren, chris, jcmvbkbc
  Cc: arnd, paulmck, david.laight.linux, glaubitz, ysato, dalias,
	linux-snps-arc, linux-csky, linux-kernel, brads

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


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-10-05 12:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-05 12:05 [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures Bradley Morgan
2026-10-05 12:05 ` [PATCH v5 1/3] ARC: Emulate two-byte cmpxchg Bradley Morgan
2026-10-05 12:08   ` Bradley Morgan
2026-10-05 12:05 ` [PATCH v5 2/3] csky: " Bradley Morgan
2026-10-05 12:05 ` [PATCH v5 3/3] xtensa: " Bradley Morgan
2026-10-05 12:06 [PATCH v5 0/3] Add two-byte cmpxchg emulation and wire it into the architectures Bradley Morgan
2026-10-05 12:06 ` [PATCH v5 1/3] ARC: Emulate two-byte cmpxchg Bradley Morgan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®