From: "Björn Töpel" <bjorn@kernel.org>
To: Chen Pei <cp0613@linux.alibaba.com>,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
memxor@gmail.com, puranjay@kernel.org
Cc: ihor.solodrai@linux.dev, eddyz87@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com, pulehui@huawei.com, pjw@kernel.org,
palmer@dabbelt.com, guoren@kernel.org, bpf@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH bpf v2] bpf, riscv: Make arena support depend on ZACAS
Date: Sun, 06 Sep 2026 16:20:37 +0200 [thread overview]
Message-ID: <874ig2pikq.fsf@all.your.base.are.belong.to.us> (raw)
In-Reply-To: <20260902061451.1416-1-cp0613@linux.alibaba.com>
Chen Pei <cp0613@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@vger.kernel.org
> Signed-off-by: Chen Pei <cp0613@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@kernel.org>
next prev parent reply other threads:[~2026-09-06 14:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 6:14 [PATCH bpf v2] bpf, riscv: Make arena support depend on ZACAS Chen Pei
2026-09-02 7:00 ` bot+bpf-ci
2026-09-05 3:08 ` Pu Lehui
2026-09-06 14:20 ` Björn Töpel [this message]
2026-09-06 14:30 ` patchwork-bot+netdevbpf
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=874ig2pikq.fsf@all.your.base.are.belong.to.us \
--to=bjorn@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cp0613@linux.alibaba.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=guoren@kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=pulehui@huawei.com \
--cc=puranjay@kernel.org \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
--cc=yonghong.song@linux.dev \
/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