From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Tejun Heo <tj@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Emil Tsalapatis <emil@etsalapatis.com>,
kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v5 05/14] bpf: Support __arena and __arena__nullable on struct_ops arguments
Date: Sat, 08 Aug 2026 02:49:36 -0700 [thread overview]
Message-ID: <19fa54535e6e94d3ec447cc413413db756456a9e.camel@gmail.com> (raw)
In-Reply-To: <20260808003938.3486067-6-memxor@gmail.com>
On Sat, 2026-08-08 at 02:39 +0200, Kumar Kartikeya Dwivedi wrote:
> From: Tejun Heo <tj@kernel.org>
>
> A struct_ops callback cannot receive an arena pointer directly, so
> passing one takes two steps. The pointer arrives as a bare u64 that the
> callback casts, and because the two sides address the arena through
> different bases it also has to be rebased by hand on the way in.
>
> Add the __arena and __arena__nullable stub argument suffixes to make this
> convenient. The callback declares the parameter as an arena pointer,
> receives it as a PTR_TO_ARENA register, and dereferences it directly,
> while the kernel caller just passes the natural kernel arena address
> (kaddr). The trampoline converts the value while saving the arguments
> into the BPF ctx, ctx[slot] = (u32)(kaddr - kern_vm_start), so the
> program never sees a kernel address and nothing rewrites the ctx after
> the fact. The converted value keeps the upper 32 bits clear as the JITs
> require of arena pointer registers and behaves like any cast_kern'ed
> arena pointer, so cast_user recovers the full user-visible address.
>
> __arena converts unconditionally and the kernel caller must not pass
> NULL. __arena__nullable preserves NULL, tested on the full 64-bit kernel
> pointer, and surfaces to the verifier as PTR_TO_ARENA (but not as a
> PTR_TO_ARENA | PTR_MAYBE_NULL). The reason is that PTR_TO_ARENA in the
> program's type state already encompasses NULL-ness, so it is not
> meaningful to force a NULL check for the program.
>
> The composite suffix intentionally ends in __nullable. Classify
> __arena__nullable before the generic suffix so scalar arena pointees do
> not take the generic nullable BTF pointer path.
>
> This patch adds the generic side. prepare_arg_info() records arena and
> nullable argument flags in the struct_ops function model, and
> bpf_tramp_arena_base() returns the arena base for a single-program
> struct_ops indirect trampoline. Only that trampoline converts: its
> program's arena is fixed at generation time. Generic trampolines can mix
> programs with different arenas and reject arena context arguments
> defensively, which is unreachable today as only struct_ops programs
> carry them. Architectures that do not implement the conversion are
> gated out at verification time with bpf_jit_supports_arena_args().
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Co-developed-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
...
next prev parent reply other threads:[~2026-08-08 9:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 0:39 [PATCH bpf-next v5 00/14] Add arena argument support to kfuncs and struct_ops Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 01/14] bpf: Rename 'early' BTF checking as a preparation phase Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 02/14] bpf: Split subprogram and kfunc collection Kumar Kartikeya Dwivedi
2026-08-08 1:59 ` bot+bpf-ci
2026-08-08 0:39 ` [PATCH bpf-next v5 03/14] bpf: Collect kfuncs after resolving program resources Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 04/14] bpf: Support __arena and __arena__nullable kfunc argument suffixes Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 05/14] bpf: Support __arena and __arena__nullable on struct_ops arguments Kumar Kartikeya Dwivedi
2026-08-08 1:17 ` sashiko-bot
2026-08-08 9:49 ` Eduard Zingerman [this message]
2026-08-08 0:39 ` [PATCH bpf-next v5 06/14] bpf, x86: JIT __arena kfunc argument rebasing Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 07/14] bpf, x86: Convert struct_ops arena arguments in the trampoline Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 08/14] selftests/bpf: Add kfunc __arena and __arena__nullable argument tests Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 09/14] selftests/bpf: Add JIT-sequence tests for __arena kfunc arguments Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 10/14] selftests/bpf: Add struct_ops __arena and __arena__nullable argument tests Kumar Kartikeya Dwivedi
2026-08-08 1:03 ` sashiko-bot
2026-08-08 0:39 ` [PATCH bpf-next v5 11/14] bpf, x86: Fix stack-passed arguments for indirect trampolines Kumar Kartikeya Dwivedi
2026-08-08 1:04 ` sashiko-bot
2026-08-08 0:39 ` [PATCH bpf-next v5 12/14] selftests/bpf: Test stack-passed struct_ops arena arguments Kumar Kartikeya Dwivedi
2026-08-08 0:39 ` [PATCH bpf-next v5 13/14] bpf: Reject tracing/freplace progs for struct_ops with arena args Kumar Kartikeya Dwivedi
2026-08-08 1:17 ` sashiko-bot
2026-08-08 9:57 ` Eduard Zingerman
2026-08-08 0:39 ` [PATCH bpf-next v5 14/14] selftests/bpf: Test attach rejection for struct_ops arena programs Kumar Kartikeya Dwivedi
2026-08-08 9:58 ` Eduard Zingerman
2026-08-08 10:10 ` [PATCH bpf-next v5 00/14] Add arena argument support to kfuncs and struct_ops 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=19fa54535e6e94d3ec447cc413413db756456a9e.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
--cc=memxor@gmail.com \
--cc=tj@kernel.org \
/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.