[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251126174016.000067f4@linux.dev>
Date: Wed, 26 Nov 2025 17:40:16 +0800
From: George Guo <dongtai.guo@...ux.dev>
To: Hengqi Chen <hengqi.chen@...il.com>
Cc: Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org, George Guo
<guodongtai@...inos.cn>
Subject: Re: [PATCH v3 0/2] LoongArch: Add 128-bit atomic cmpxchg support
(v3)
On Wed, 26 Nov 2025 13:23:57 +0800
Hengqi Chen <hengqi.chen@...il.com> wrote:
> On Wed, Nov 26, 2025 at 10:06 AM George Guo <dongtai.guo@...ux.dev>
> wrote:
> >
> > This patch series adds 128-bit atomic compare-and-exchange support
> > for LoongArch architecture, which fixes BPF scheduler test failures
> > caused by missing 128-bit atomics support.
> >
> > The series consists of two patches:
> >
> > 1. "LoongArch: Add 128-bit atomic cmpxchg support"
> > - Implements 128-bit atomic compare-and-exchange using
> > LoongArch's LL.D/SC.Q instructions
> > - Fixes BPF scheduler test failures (scx_central scx_qmap) where
> > kmalloc_nolock_noprof returns NULL due to missing 128-bit
> > atomics, leading to -ENOMEM errors during scheduler initialization
> >
>
> This kmalloc_nolock_noprof() was introduced in v6.18-rc1 and has no
> caller for now.
> Why is this related to the sched_ext failure ?
>
Hi Hengqi,
When running scx_central, function call chain as below:
central_init->bpf_timer_init->__bpf_async_init->bpf_map_kmalloc_nolock->kmalloc_nolock
->kmalloc_nolock_noprof
The function kmalloc_nolock_noprof returns NULL due to the following
condition:
if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s))
/*
* kmalloc_nolock() is not supported on architectures that
* don't implement cmpxchg16b, but debug caches don't use
* per-cpu slab and per-cpu partial slabs. They rely on
* kmem_cache_node->list_lock, so kmalloc_nolock() can
* attempt to allocate from debug caches by
* spin_trylock_irqsave(&n->list_lock, ...)
*/
return NULL;
The NULL return occurs because kmalloc_nolock is not supported on
Loongarch, which don't implement cmpxchg16b. So I am giving the patch.
Also I tried with debug caches(CONFIG_SLUB_DEBUG_ON=y), it works,
but not a good idea.
> > 2. "LoongArch: Enable 128-bit atomics cmpxchg support"
> > - Adds select HAVE_CMPXCHG_DOUBLE and select
> > HAVE_ALIGNED_STRUCT_PAGE in Kconfig to enable 128-bit atomic
> > cmpxchg support
> >
> > The issue was identified through BPF scheduler test failures where
> > scx_central and scx_qmap schedulers would fail to initialize.
> > Testing was performed using the scx_qmap scheduler from
> > tools/sched_ext/, confirming that the patches resolve the
> > initialization failures.
> >
> > Signed-off-by: George Guo <dongtai.guo@...ux.dev>
> > ---
> > Changes in v3:
> > - dbar 0 -> __WEAK_LLSC_MB
> > - =ZB" (__ptr[0]) -> "r" (__ptr)
> > - Link to v2:
> > https://lore.kernel.org/r/20251124-2-v2-0-b38216e25fd9@linux.dev
> >
> > Changes in v2:
> > - Use a normal ld.d for the high word instead of ll.d to avoid race
> > condition
> > - Insert a dbar between ll.d and ld.d to prevent reordering
> > - Simply __cmpxchg128_asm("ll.d", "sc.q", ptr, o, n) to
> > __cmpxchg128_asm(ptr, o, n)
> > - Fix address operand constraints after testing different
> > approaches:
> > * ld.d with "m"
> > * ll.d with "ZC",
> > * sc.q with "ZB"(alternative constraints caused issues:
> > - "r" caused system hang
> > - "ZC" caused compiler error:
> > {standard input}: Assembler messages:
> > {standard input}:10037: Fatal error: Immediate overflow.
> > format: u0:0 )
> > - Link to v1:
> > https://lore.kernel.org/r/20251120-2-v1-0-705bdc440550@linux.dev
> >
> > ---
> > George Guo (2):
> > LoongArch: Add 128-bit atomic cmpxchg support
> > LoongArch: Enable 128-bit atomics cmpxchg support
> >
> > arch/loongarch/Kconfig | 2 ++
> > arch/loongarch/include/asm/cmpxchg.h | 47
> > ++++++++++++++++++++++++++++++++++++ 2 files changed, 49
> > insertions(+) ---
> > base-commit: d5ae5ac32615e4af729f0610fdc11ff4f4798aef
> > change-id: 20251120-2-d03862b2cf6d
> >
> > Best regards,
> > --
> > George Guo <dongtai.guo@...ux.dev>
> >
> >
Powered by blists - more mailing lists