From: David Laight <david.laight.linux@gmail.com>
To: 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>,
"Paul E . McKenney" <paulmck@kernel.org>,
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 v3 0/5] Add two-byte cmpxchg emulation and wire it into the architectures
Date: Fri, 18 Sep 2026 10:10:04 +0100 [thread overview]
Message-ID: <20260918101004.731bf2e5@pumpkin> (raw)
In-Reply-To: <20260917163830.3748-1-brads@mainlining.org>
On Thu, 17 Sep 2026 16:38:25 +0000
Bradley Morgan <brads@mainlining.org> wrote:
> This is v3 of the two byte cmpxchg emulation series, wiring
> cmpxchg_emu_u16() into arc, csky, sh and xtensa.
>
> v2 tried u16 as the parameter type. David Laight pointed out that
> this 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. v3 takes the old and new
> values as unsigned long and casts 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
> of the emulated halfword, which matches hardware cmpxchg r16
> behaviour, and a host test of 972 cases across both halfword offsets
> against a byte level reference model still passes.
>
> David also noted the missing pointer to integer type check in some
> of the macros, so cmpxchg(&p, 4, 5) compiled silently. The csky
> macros typed __old and __new through __typeof__(old), which skips
> the check, and sh had none either. Both now type check through
> (unsigned long)(0 ? *(ptr) : (old)), the idiom David suggested,
> which keeps the pointer to integer conversion explicit while making
> the compiler reject mismatched types. Both of his test cases now
> fail to compile on every macro shape.
You fixed csky but not the others.
I guess that could be a separate patch (maybe series).
David
>
> The ARMv6 wiring stays dropped from v1, per Arnd Bergmann's offer to
> take the INTEGRATOR_CM1136JFS cleanup in his platform removal series.
>
> Thank you, Paul McKenney for suggesting this, and David Laight and
> Arnd Bergmann for the review that shaped all three revisions.
>
> Bradley Morgan (5):
> lib: Add two-byte cmpxchg emulation function
> ARC: Emulate two-byte cmpxchg
> csky: Emulate two-byte cmpxchg
> sh: Emulate two-byte cmpxchg
> xtensa: Emulate two-byte cmpxchg
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <david.laight.linux@gmail.com>
To: 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>,
"Paul E . McKenney" <paulmck@kernel.org>,
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 v3 0/5] Add two-byte cmpxchg emulation and wire it into the architectures
Date: Fri, 18 Sep 2026 10:10:04 +0100 [thread overview]
Message-ID: <20260918101004.731bf2e5@pumpkin> (raw)
In-Reply-To: <20260917163830.3748-1-brads@mainlining.org>
On Thu, 17 Sep 2026 16:38:25 +0000
Bradley Morgan <brads@mainlining.org> wrote:
> This is v3 of the two byte cmpxchg emulation series, wiring
> cmpxchg_emu_u16() into arc, csky, sh and xtensa.
>
> v2 tried u16 as the parameter type. David Laight pointed out that
> this 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. v3 takes the old and new
> values as unsigned long and casts 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
> of the emulated halfword, which matches hardware cmpxchg r16
> behaviour, and a host test of 972 cases across both halfword offsets
> against a byte level reference model still passes.
>
> David also noted the missing pointer to integer type check in some
> of the macros, so cmpxchg(&p, 4, 5) compiled silently. The csky
> macros typed __old and __new through __typeof__(old), which skips
> the check, and sh had none either. Both now type check through
> (unsigned long)(0 ? *(ptr) : (old)), the idiom David suggested,
> which keeps the pointer to integer conversion explicit while making
> the compiler reject mismatched types. Both of his test cases now
> fail to compile on every macro shape.
You fixed csky but not the others.
I guess that could be a separate patch (maybe series).
David
>
> The ARMv6 wiring stays dropped from v1, per Arnd Bergmann's offer to
> take the INTEGRATOR_CM1136JFS cleanup in his platform removal series.
>
> Thank you, Paul McKenney for suggesting this, and David Laight and
> Arnd Bergmann for the review that shaped all three revisions.
>
> Bradley Morgan (5):
> lib: Add two-byte cmpxchg emulation function
> ARC: Emulate two-byte cmpxchg
> csky: Emulate two-byte cmpxchg
> sh: Emulate two-byte cmpxchg
> xtensa: Emulate two-byte cmpxchg
_______________________________________________
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-18 9:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 16:38 [PATCH v3 0/5] Add two-byte cmpxchg emulation and wire it into the architectures Bradley Morgan
2026-09-17 16:38 ` Bradley Morgan
2026-09-17 16:38 ` [PATCH v3 1/5] lib: Add two-byte cmpxchg emulation function Bradley Morgan
2026-09-17 16:38 ` Bradley Morgan
2026-09-18 8:59 ` David Laight
2026-09-18 8:59 ` David Laight
2026-09-17 16:38 ` [PATCH v3 2/5] ARC: Emulate two-byte cmpxchg Bradley Morgan
2026-09-17 16:38 ` Bradley Morgan
2026-09-17 16:38 ` [PATCH v3 3/5] csky: " Bradley Morgan
2026-09-17 16:38 ` Bradley Morgan
2026-09-17 16:38 ` [PATCH v3 4/5] sh: " Bradley Morgan
2026-09-17 16:38 ` Bradley Morgan
2026-09-17 16:38 ` [PATCH v3 5/5] xtensa: " Bradley Morgan
2026-09-17 16:38 ` Bradley Morgan
2026-09-17 16:42 ` Bradley Morgan
2026-09-17 16:42 ` Bradley Morgan
2026-09-18 9:10 ` David Laight [this message]
2026-09-18 9:10 ` [PATCH v3 0/5] Add two-byte cmpxchg emulation and wire it into the architectures 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=20260918101004.731bf2e5@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=brads@mainlining.org \
--cc=chris@zankel.net \
--cc=dalias@libc.org \
--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=vgupta@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.