All of lore.kernel.org
 help / color / mirror / Atom feed
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>


WARNING: multiple messages have this Message-ID (diff)
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>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2026-09-06 14:20 UTC|newest]

Thread overview: 10+ 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  6:14 ` Chen Pei
2026-09-02  7:00 ` bot+bpf-ci
2026-09-02  7:00   ` bot+bpf-ci
2026-09-05  3:08 ` Pu Lehui
2026-09-05  3:08   ` Pu Lehui
2026-09-06 14:20 ` Björn Töpel [this message]
2026-09-06 14:20   ` Björn Töpel
2026-09-06 14:30 ` patchwork-bot+netdevbpf
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.