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

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Sat Jul 18, 2026 at 3:33 AM CEST, Eduard Zingerman wrote:
> 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.
>

I considered some of these options.

I think this is reasonable for kfuncs. We can retain move to R0 for JITs without
that predicate. But what do we do for struct_ops? Earlier prototype had to reload,
translate the arg, and store it back into ctx. IMO that's way uglier than just
translating while storing into the ctx during save_args().

At that point, the argument for avoiding JIT-specific code in favor of generic
sequences becomes a lot weaker.

Now we can argue for having some way to inject generic bytecode sequence in the
trampoline before BPF program is called, but that requires more conversation.
This case would be the only user. If we have more, it is probably worth a
consideration.

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

Just imagine multiple arena arguments. Let's think beyond the immediate use case
for a moment (in scx). With the test+branch, that's way too many instructions
before each function call to translate each argument. In scx I think one of the
kfunc / struct_ops callback already did not need __nullable. In general it also
stays more consistent with us opting into __nullable for arguments, than having
it by default.

Yes, __arena means different things in different places, the meaning is now
context-dependent. In the program, it just indicates global function takes arena
pointer. NULL-ness or not distinction is erased, just like for PTR_TO_ARENA. For
kfuncs, the translation happens from program to kernel, for struct_ops, from
kernel to program. Better naming can probably avoid some of the overloading, but
anything else seems uglier to spell out.

> ===
>
> 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?

We can gate this new one behind type tag support in GCC, and begin using those
instead. That still won't allow unification with KF_ARENA_* ones.