[PATCH bpf v2] bpf, riscv: Make arena support depend on ZACAS
Björn Töpel
bjorn at kernel.org
Sun Sep 6 07:20:37 PDT 2026
Chen Pei <cp0613 at linux.alibaba.com> writes:
> The arena range tree allocates its nodes with kmalloc_nolock() since
> commit f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree").
> kmalloc_nolock() requires slab caches with cmpxchg128 support
> (__CMPXCHG_DOUBLE); on riscv cmpxchg128 is provided by the ZACAS
> extension. On systems without ZACAS every arena map creation fails
> with a misleading -ENOMEM.
>
> Report the missing support instead: make bpf_jit_supports_arena()
> return system_has_cmpxchg128() where it is defined, so arena map
> creation fails with -EOPNOTSUPP on systems without ZACAS. The macro
> is only defined when both CONFIG_RISCV_ISA_ZACAS and
> CONFIG_TOOLCHAIN_HAS_ZACAS are enabled, so guard it with #ifdef the
> same way mm/slab.h consumes it, and reject arena otherwise. This
> matches how arena BPF_CMPXCHG instructions are already gated on ZACAS
> in bpf_jit_supports_insn().
>
> Fixes: f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree")
> Cc: stable at vger.kernel.org
> Signed-off-by: Chen Pei <cp0613 at linux.alibaba.com>
> ---
> Changes since v1:
> - Guard system_has_cmpxchg128() with #ifdef instead of calling it
> unconditionally: the macro is only defined when both
> CONFIG_RISCV_ISA_ZACAS and CONFIG_TOOLCHAIN_HAS_ZACAS are enabled
> (as reported by sashiko-bot), so v1 broke the build when either
> was disabled. This mirrors how mm/slab.h consumes the macro.
>
> Why #ifdef rather than rv_ext_enabled(ZACAS)? The predicates differ
> exactly in the configurations that matter:
>
> scenario (ISA_ZACAS/TOOLCHAIN/hw) v1 rv_ext_enabled #ifdef
> ISA=n or TOOLCHAIN=n build fails rejects rejects
> ISA=y TOOLCHAIN=n hw has ZACAS build fails accepts, then rejects
> -ENOMEM again
> ISA=y TOOLCHAIN=y hw has ZACAS exact exact exact
Thanks for clarifying this; Yeah, ZACAS requires runtime *and* toolchain
support.
Acked-by: Björn Töpel <bjorn at kernel.org>
More information about the linux-riscv
mailing list