From: George Guo <dongtai.guo@linux.dev>
To: hev <r@hev.cc>
Cc: Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
George Guo <guodongtai@kylinos.cn>
Subject: Re: [PATCH v2 1/2] LoongArch: Add 128-bit atomic cmpxchg support
Date: Tue, 25 Nov 2025 10:43:16 +0800 [thread overview]
Message-ID: <20251125104316.00001294@linux.dev> (raw)
In-Reply-To: <CAHirt9gjjULM6CGDR2pHJkQAKMsoZ8kpqtPn79psJQP1uu6FsA@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB18030, Size: 4499 bytes --]
On Mon, 24 Nov 2025 19:37:40 +0800
hev <r@hev.cc> wrote:
> On Mon, Nov 24, 2025 at 5:286§2PM George Guo <dongtai.guo@linux.dev>
> wrote:
> >
> > From: George Guo <guodongtai@kylinos.cn>
> >
> > Implement 128-bit atomic compare-and-exchange using LoongArch's
> > LL.D/SC.Q instructions.
> >
> > At the same time, fix BPF scheduler test failures (scx_central
> > scx_qmap) caused by kmalloc_nolock_noprof returning NULL due to
> > missing 128-bit atomics. The NULL returns led to -ENOMEM errors
> > during scheduler initialization, causing test cases to fail.
> >
> > Verified by testing with the scx_qmap scheduler (located in
> > tools/sched_ext/). Building with `make` and running
> > ./tools/sched_ext/build/bin/scx_qmap.
> >
> > Signed-off-by: George Guo <guodongtai@kylinos.cn>
> > ---
> > arch/loongarch/include/asm/cmpxchg.h | 47
> > ++++++++++++++++++++++++++++++++++++ 1 file changed, 47
> > insertions(+)
> >
> > diff --git a/arch/loongarch/include/asm/cmpxchg.h
> > b/arch/loongarch/include/asm/cmpxchg.h index
> > 979fde61bba8a42cb4f019f13ded2a3119d4aaf4..757f6e82b9880d04f4883dc9a802312111aa4588
> > 100644 --- a/arch/loongarch/include/asm/cmpxchg.h +++
> > b/arch/loongarch/include/asm/cmpxchg.h @@ -111,6 +111,44 @@
> > __arch_xchg(volatile void *ptr, unsigned long x, int size) __ret;
> > \ })
> >
> > +union __u128_halves {
> > + u128 full;
> > + struct {
> > + u64 low;
> > + u64 high;
> > + };
> > +};
> > +
> > +#define __cmpxchg128_asm(ptr, old, new)
> > \ +({
> > \
> > + union __u128_halves __old, __new, __ret;
> > \
> > + volatile u64 *__ptr = (volatile u64 *)(ptr);
> > \
> > +
> > \
> > + __old.full = (old);
> > \
> > + __new.full = (new);
> > \
> > +
> > \
> > + __asm__ __volatile__(
> > \
> > + "1: ll.d %0, %3 # 128-bit cmpxchg low \n"
> > \
> > + " dbar 0 # memory barrier \n"
> > \
> > + " ld.d %1, %4 # 128-bit cmpxchg high \n"
> > \
> > + " bne %0, %z5, 2f \n"
> > \
> > + " bne %1, %z6, 2f \n"
> > \
> > + " move $t0, %z7 \n"
> > \
> > + " move $t1, %z8 \n"
> > \
> > + " sc.q $t0, $t1, %2 \n"
> > \
> > + " beqz $t0, 1b \n"
> > \
> > + "2: \n"
> > \
> > + __WEAK_LLSC_MB
> > \
> > + : "=&r" (__ret.low), "=&r" (__ret.high),
> > \
> > + "=ZB" (__ptr[0])
> > \
>
> "ZB" isn't a legal constraint for the address operand in sc.q. When
> assembled, it turns into something like sc.q $r,$r,$r,0, which clearly
> doesn't match the instruction format, yet gas happily accepts it wheil
> clang rightfully rejects it. Classic GNU-as leniency biting again. :)
>
Hi Hev,
Thanks for your advice, I tried sc.q with r or ZC. the result as
below: (with gcc 14.2.1 in fedora-42)
- sc.q with "r" caused system hang
- sc.q with "ZC" caused compiler error:
{standard input}: Assembler messages:
{standard input}:10037: Fatal error: Immediate overflow.
format: u0:0 )
> > + : "ZC" (__ptr[0]), "m" (__ptr[1]),
> > \
> > + "Jr" (__old.low), "Jr" (__old.high),
> > \
> > + "Jr" (__new.low), "Jr" (__new.high)
> > \
> > + : "t0", "t1", "memory");
> > \
> > +
> > \
> > + __ret.full;
> > \ +})
> > +
> > static inline unsigned int __cmpxchg_small(volatile void *ptr,
> > unsigned int old, unsigned int new, unsigned int size)
> > {
> > @@ -198,6 +236,15 @@ __cmpxchg(volatile void *ptr, unsigned long
> > old, unsigned long new, unsigned int __res;
> > \ })
> >
> > +/* cmpxchg128 */
> > +#define system_has_cmpxchg128() 1
> > +
> > +#define arch_cmpxchg128(ptr, o, n)
> > \ +({
> > \
> > + BUILD_BUG_ON(sizeof(*(ptr)) != 16);
> > \
> > + __cmpxchg128_asm(ptr, o, n); \
> > +})
> > +
> > #ifdef CONFIG_64BIT
> > #define arch_cmpxchg64_local(ptr, o, n)
> > \ ({
> > \
> >
> > --
> > 2.48.1
> >
> >
>
next prev parent reply other threads:[~2025-11-25 2:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-24 9:26 [PATCH v2 0/2] LoongArch: Add 128-bit atomic cmpxchg support (v2) George Guo
2025-11-24 9:26 ` [PATCH v2 1/2] LoongArch: Add 128-bit atomic cmpxchg support George Guo
2025-11-24 11:37 ` hev
2025-11-25 2:43 ` George Guo [this message]
2025-11-25 3:04 ` Xi Ruoyao
[not found] ` <b5de6a2e-a700-4687-b483-2d60e309de25@loongson.cn>
2025-11-25 8:01 ` Xi Ruoyao
2025-11-25 3:32 ` hev
2025-11-24 9:26 ` [PATCH v2 2/2] LoongArch: Enable 128-bit atomics " George Guo
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=20251125104316.00001294@linux.dev \
--to=dongtai.guo@linux.dev \
--cc=chenhuacai@kernel.org \
--cc=guodongtai@kylinos.cn \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=r@hev.cc \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox