Re: [PATCH v1 1/2] LoongArch: BPF: Make arena support depend on SCQ extension

[Tiezhu Yang <yangtiezhu@loongson.cn>]

On 11/4/26 6:17 PM, George Guo wrote:
> Hi Tiezhu,
> 
> On 2026/11/2 15:28, Tiezhu Yang wrote:
>> This is because the arena range tree uses kmalloc_nolock(), which requires
>> 128-bit atomic cmpxchg support, provided by SCQ extension on LoongArch.
> 
> There is an existing SLUB debug fallback worth checking before making
> arena support depend on SCQ.
> 
> In __kmalloc_nolock_noprof(), the rejection condition is:
> 
>          if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s))
>                  return NULL;
> 
> Debug caches do not require cmpxchg128 for this path. They use
> kmem_cache_node->list_lock with spin_trylock_irqsave() instead.
> With CONFIG_SLUB_DEBUG=y, booting with slab_debug enables this path;
> CONFIG_SLUB_DEBUG_ON=y enables debugging by default as well.
> 
> The proposed bpf_jit_supports_arena() check would reject arena maps on
> CPUs without SCQ, even when the SLUB debug fallback is available.
> This would prevent us from running arena tests on those machines
> with slab_debug enabled.
> 
> Could you rerun jit_insns/cast_to_user on the 3A5000 with slab_debug
> enabled, before and after this patch? The claim that kmalloc_nolock()
> requires 128-bit cmpxchg should account for debug caches, and it would
> be useful to preserve that fallback when addressing the error reporting.

I noticed that a similar concern regarding the slub_debug exception
was previously raised by the CI bot in the RISC-V ZACAS patch:
https://lore.kernel.org/bpf/594ed4944926f6a7202b016eca03d879d11bfdf09a2cbaea039421ae4ab962c0@mail.kernel.org/

I highly agree with the bot's conclusion there:
 > "That narrowing is arguably desirable (BPF should not depend on a SLUB
 > debug-mode escape hatch)."

Moreover, handling this runtime debug mode inside the architecture's JIT
layer would inevitably introduce undesirable cross-module coupling with
SLUB internals. Restricting the JIT capability solely to native hardware
and toolchain support keeps the implementation clean and robust.

Thanks,
Tiezhu