From: Vineet Gupta <vgupta@kernel.org>
To: paulmck@kernel.org, Bradley Morgan <brads@mainlining.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vineet Gupta <vgupta@kernel.org>, Guo Ren <guoren@kernel.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
David Laight <david.laight.linux@gmail.com>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
linux-snps-arc@lists.infradead.org, linux-csky@vger.kernel.org,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] Add two-byte cmpxchg emulation and wire it into the architectures
Date: Tue, 22 Sep 2026 12:13:42 -0700 [thread overview]
Message-ID: <ddde3609-f068-4f26-92c0-e9244f290eaf@kernel.org> (raw)
In-Reply-To: <9a7883a3-a1b1-4d37-8234-f4c62b2e6e27@paulmck-laptop>
On 9/22/26 11:59, Paul E. McKenney wrote:
> On Tue, Sep 22, 2026 at 07:37:54PM +0100, Bradley Morgan wrote:
>> On 22 September 2026 19:29:32 BST, "Paul E. McKenney" <paulmck@kernel.org>
>> wrote:
>>> On Tue, Sep 22, 2026 at 05:33:49PM +0000, Bradley Morgan wrote:
>>>> This is v4 of the two byte cmpxchg emulation series, wiring
>>>> cmpxchg_emu_u16() into arc, csky, sh and xtensa.
>>>>
>>>> v3 had changed cmpxchg_emu_u8()'s success return to (u16)old, which was
>>>> a 16-bit mask in the 8-bit function, and a dead one at that, since the
>>>> compare guarantees the low 8 bits of old are the byte being returned.
>>>> David Laight asked where that cast came from. v4 returns old unmasked,
>>>> the exact behaviour the one-byte emulator always had, so nothing that
>>>> uses cmpxchg_emu_u8() through the widened prototypes sees a change.
>>>>
>>>> David also noted v3 extended the (unsigned long)(0 ? *ptr : (old)) type
>>>> check to csky and sh but not arc and xtensa. v4 adds it there too, so a
>>>> cmpxchg(&p, 4, 5) fails to compile on every architecture in the series,
>>>> verified with each architecture's macro instantiated standalone.
>>>>
>>>> While adding the type check to arc, the switch subject turned out to be
>>>> sizeof((_p_)), the pointer, not sizeof(*(_p_)), the pointee. On 32-bit
>>>> arc the switch was always 4, so the size 1 and size 2 cases were dead
>>>> code and every sub-word cmpxchg() went through the 32-bit llock/scond
>>>> pair, comparing whole words against sub-word values, so the compare
>>>> almost never succeeded. The switch now tests the pointee, and the u8
>>>> path it was always meant to dispatch actually runs, so the one-byte
>>>> emulation works on arc for the first time since the sizeof bug landed
>>>> with the original cmpxchg_emu_u8() wiring.
>>>>
>>>> The host test of 972 cases across both halfword offsets against a byte
>>>> level reference model still passes, and a 20000 case randomized run
>>>> checking the masked compare and return against a hardware cmpxchg r16
>>>> model passes with zero mismatches.
>>>>
>>>> David pointed out on v1 that a u16 prototype does not compile warning
>>>> free when exchanging a pointer type, because the switch statements in
>>>> the architecture macros instantiate every size case, so a pointer
>>>> cmpxchg() type checks the two byte case, and the (u16) casts there
>>>> warn. v4 keeps taking the old and new values as unsigned long and
>>>> casting to u16 inside the function, so the call sites need no narrowing
>>>> casts and pointer exchanges compile clean. The function still compares
>>>> and returns exactly the 16 bits the caller asked for, which matches
>>>> hardware cmpxchg r16 behaviour.
>>>>
>>>> The ARMv6 wiring stays dropped from v1, per Arnd Bergmann's offer to
>>>> take the INTEGRATOR_CM1136JFS cleanup in his platform removal series.
>>> I have pulled these in, but only to expose them to things like the kernel
>>> test robot. My guess is that they will go in by some other path.
>>>
>>> And to that end:
>>>
>>> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
>>>
>>> But I could of course easily be missing subtle arch-specific bugs.
>> There are, according to sashiko, but I can't seem to make that thing happy
>> no matter what I do
> Hahahahaha!!!
>
> We forgot to CC the architecture maintainers.
No you didn't - they were CC'ed all along.
I'll give this is a test run and report back later.
Both the cover letter and 1/5 explain what is being done and not clearly
why ?
Is there an existing or proposed user for this API.
Otherwise it will just bit-rot. No big deal from arch code pov but just
saying...
Thx,
-Vineet
>
> For the changes to lib/cmpxchg-emu.c:
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arnd Bergmann <arnd@kernel.org>
>
> For ARC:
>
> Cc: Vineet Gupta <vgupta@kernel.org>
> linux-snps-arc@lists.infradead.org
>
> For sh:
>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: <linux-sh@vger.kernel.org>
>
> For csky:
>
> Cc: Guo Ren <guoren@kernel.org>
> Cc: <linux-csky@vger.kernel.org>
> Cc: <linux-kernel@vger.kernel.org>
>
> For xtensa:
>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
>
> They might be willing to help. ;-)
>
> Thanx, Paul
>
>>>> Bradley Morgan (5):
>>>> lib: Add two-byte cmpxchg emulation function
>>>> ARC: Emulate two-byte cmpxchg
>>>> sh: Emulate two-byte cmpxchg
>>>> csky: Emulate two-byte cmpxchg
>>>> xtensa: Emulate two-byte cmpxchg
>> --- Thanks!
>> "I'm not a very positive person" - Linus torvalds
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <vgupta@kernel.org>
To: paulmck@kernel.org, Bradley Morgan <brads@mainlining.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vineet Gupta <vgupta@kernel.org>, Guo Ren <guoren@kernel.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
David Laight <david.laight.linux@gmail.com>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
linux-snps-arc@lists.infradead.org, linux-csky@vger.kernel.org,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] Add two-byte cmpxchg emulation and wire it into the architectures
Date: Tue, 22 Sep 2026 12:13:42 -0700 [thread overview]
Message-ID: <ddde3609-f068-4f26-92c0-e9244f290eaf@kernel.org> (raw)
In-Reply-To: <9a7883a3-a1b1-4d37-8234-f4c62b2e6e27@paulmck-laptop>
On 9/22/26 11:59, Paul E. McKenney wrote:
> On Tue, Sep 22, 2026 at 07:37:54PM +0100, Bradley Morgan wrote:
>> On 22 September 2026 19:29:32 BST, "Paul E. McKenney" <paulmck@kernel.org>
>> wrote:
>>> On Tue, Sep 22, 2026 at 05:33:49PM +0000, Bradley Morgan wrote:
>>>> This is v4 of the two byte cmpxchg emulation series, wiring
>>>> cmpxchg_emu_u16() into arc, csky, sh and xtensa.
>>>>
>>>> v3 had changed cmpxchg_emu_u8()'s success return to (u16)old, which was
>>>> a 16-bit mask in the 8-bit function, and a dead one at that, since the
>>>> compare guarantees the low 8 bits of old are the byte being returned.
>>>> David Laight asked where that cast came from. v4 returns old unmasked,
>>>> the exact behaviour the one-byte emulator always had, so nothing that
>>>> uses cmpxchg_emu_u8() through the widened prototypes sees a change.
>>>>
>>>> David also noted v3 extended the (unsigned long)(0 ? *ptr : (old)) type
>>>> check to csky and sh but not arc and xtensa. v4 adds it there too, so a
>>>> cmpxchg(&p, 4, 5) fails to compile on every architecture in the series,
>>>> verified with each architecture's macro instantiated standalone.
>>>>
>>>> While adding the type check to arc, the switch subject turned out to be
>>>> sizeof((_p_)), the pointer, not sizeof(*(_p_)), the pointee. On 32-bit
>>>> arc the switch was always 4, so the size 1 and size 2 cases were dead
>>>> code and every sub-word cmpxchg() went through the 32-bit llock/scond
>>>> pair, comparing whole words against sub-word values, so the compare
>>>> almost never succeeded. The switch now tests the pointee, and the u8
>>>> path it was always meant to dispatch actually runs, so the one-byte
>>>> emulation works on arc for the first time since the sizeof bug landed
>>>> with the original cmpxchg_emu_u8() wiring.
>>>>
>>>> The host test of 972 cases across both halfword offsets against a byte
>>>> level reference model still passes, and a 20000 case randomized run
>>>> checking the masked compare and return against a hardware cmpxchg r16
>>>> model passes with zero mismatches.
>>>>
>>>> David pointed out on v1 that a u16 prototype does not compile warning
>>>> free when exchanging a pointer type, because the switch statements in
>>>> the architecture macros instantiate every size case, so a pointer
>>>> cmpxchg() type checks the two byte case, and the (u16) casts there
>>>> warn. v4 keeps taking the old and new values as unsigned long and
>>>> casting to u16 inside the function, so the call sites need no narrowing
>>>> casts and pointer exchanges compile clean. The function still compares
>>>> and returns exactly the 16 bits the caller asked for, which matches
>>>> hardware cmpxchg r16 behaviour.
>>>>
>>>> The ARMv6 wiring stays dropped from v1, per Arnd Bergmann's offer to
>>>> take the INTEGRATOR_CM1136JFS cleanup in his platform removal series.
>>> I have pulled these in, but only to expose them to things like the kernel
>>> test robot. My guess is that they will go in by some other path.
>>>
>>> And to that end:
>>>
>>> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
>>>
>>> But I could of course easily be missing subtle arch-specific bugs.
>> There are, according to sashiko, but I can't seem to make that thing happy
>> no matter what I do
> Hahahahaha!!!
>
> We forgot to CC the architecture maintainers.
No you didn't - they were CC'ed all along.
I'll give this is a test run and report back later.
Both the cover letter and 1/5 explain what is being done and not clearly
why ?
Is there an existing or proposed user for this API.
Otherwise it will just bit-rot. No big deal from arch code pov but just
saying...
Thx,
-Vineet
>
> For the changes to lib/cmpxchg-emu.c:
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arnd Bergmann <arnd@kernel.org>
>
> For ARC:
>
> Cc: Vineet Gupta <vgupta@kernel.org>
> linux-snps-arc@lists.infradead.org
>
> For sh:
>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: <linux-sh@vger.kernel.org>
>
> For csky:
>
> Cc: Guo Ren <guoren@kernel.org>
> Cc: <linux-csky@vger.kernel.org>
> Cc: <linux-kernel@vger.kernel.org>
>
> For xtensa:
>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
>
> They might be willing to help. ;-)
>
> Thanx, Paul
>
>>>> Bradley Morgan (5):
>>>> lib: Add two-byte cmpxchg emulation function
>>>> ARC: Emulate two-byte cmpxchg
>>>> sh: Emulate two-byte cmpxchg
>>>> csky: Emulate two-byte cmpxchg
>>>> xtensa: Emulate two-byte cmpxchg
>> --- Thanks!
>> "I'm not a very positive person" - Linus torvalds
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
next prev parent reply other threads:[~2026-09-22 19:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 17:33 [PATCH v4 0/5] Add two-byte cmpxchg emulation and wire it into the architectures Bradley Morgan
2026-09-22 17:33 ` Bradley Morgan
2026-09-22 17:33 ` [PATCH 1/5] lib: Add two-byte cmpxchg emulation function Bradley Morgan
2026-09-22 17:33 ` Bradley Morgan
2026-09-22 17:33 ` [PATCH 2/5] ARC: Emulate two-byte cmpxchg Bradley Morgan
2026-09-22 17:33 ` Bradley Morgan
2026-09-23 9:30 ` David Laight
2026-09-23 9:30 ` David Laight
2026-09-22 17:33 ` [PATCH 3/5] sh: " Bradley Morgan
2026-09-22 17:33 ` Bradley Morgan
2026-09-23 9:28 ` David Laight
2026-09-23 9:28 ` David Laight
2026-09-22 17:33 ` [PATCH 4/5] csky: " Bradley Morgan
2026-09-22 17:33 ` Bradley Morgan
2026-09-22 17:33 ` [PATCH 5/5] xtensa: " Bradley Morgan
2026-09-22 17:33 ` Bradley Morgan
2026-09-22 18:29 ` [PATCH v4 0/5] Add two-byte cmpxchg emulation and wire it into the architectures Paul E. McKenney
2026-09-22 18:29 ` Paul E. McKenney
2026-09-22 18:37 ` Bradley Morgan
2026-09-22 18:37 ` Bradley Morgan
2026-09-22 18:59 ` Paul E. McKenney
2026-09-22 18:59 ` Paul E. McKenney
2026-09-22 19:03 ` Bradley Morgan
2026-09-22 19:03 ` Bradley Morgan
2026-09-22 19:36 ` Paul E. McKenney
2026-09-22 19:36 ` Paul E. McKenney
2026-09-22 19:13 ` Vineet Gupta [this message]
2026-09-22 19:13 ` Vineet Gupta
2026-09-22 19:53 ` Paul E. McKenney
2026-09-22 19:53 ` Paul E. McKenney
2026-09-23 9:32 ` David Laight
2026-09-23 9:32 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddde3609-f068-4f26-92c0-e9244f290eaf@kernel.org \
--to=vgupta@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=brads@mainlining.org \
--cc=chris@zankel.net \
--cc=dalias@libc.org \
--cc=david.laight.linux@gmail.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=guoren@kernel.org \
--cc=jcmvbkbc@gmail.com \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=paulmck@kernel.org \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.