Re: [PATCH bpf-next v1 3/9] bpf, x86: JIT __arena kfunc argument rebasing

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2026-07-16 at 00:00 +0200, Kumar Kartikeya Dwivedi wrote:
> From: Tejun Heo <tj@kernel.org>
> 
> Implement arena argument rebasing for kfunc calls on x86. R12 already
> holds kern_vm_start whenever the prog has an arena, so each tagged
> argument costs two instructions emitted right before the call:
> 
>   movl %eN, %eN         /* truncate, clear the upper 32 bits */
>   addq %r12, %rN
> 
> A nullable argument tests the truncated value and jumps over the add:
> 
>   movl  %eN, %eN
>   testl %eN, %eN
>   jz    1f
>   addq  %r12, %rN
> 1:
> 
> addq carries a REX prefix for every argument register and is always
> three bytes, so the jz displacement is constant. The sequence is native
> code generated after constant blinding has run on the BPF instruction
> stream, so blinding never sees the rebase and needs no special handling.
> 
> bpf_jit_supports_arena_args() is not flipped yet; that happens when the
> struct_ops trampoline side is in place as well.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
>  arch/x86/net/bpf_jit_comp.c | 49 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)

Hi Kumar, Tejun,

Sorry for the delayed response.

I'd like to push back on the JIT based approach.
As far as I understand, it saves a 64-immediate move per callsite,
for jits that have dedicated arena registers (all but s390),
but it puts implementation burden on each jit.

There is an easy workaround regarding 64-immediate move:
use R0 as in the original patch-set by default,
add a jit_has_dedicated_arena_register() predicate +
and encoding to address this register from __internal__
bpf instruction, say BPF_REG_12.

I'd prefer to keep the bulk of the implementation in one place instead
of verifier.c + 6 jits.

===

Tangential to this, I think that __arena vs __arena_nullable is a footgun.
Is it really so performance critical to avoid this null check?

===

On more tangential, these flags would represent a third way to encode
arena arguments we already have:
- KF_ARENA_ARG{1,2} for kfuncs
- ARG_TAG_ARENA for global functions.

Any ideas on how to unify these?