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

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

On Sun Jul 26, 2026 at 4:22 AM CEST, bot+bpf-ci wrote:
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index b2feec81e231..08013c2fcfaa 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
>> @@ -1678,6 +1678,50 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
>>  	return 0;
>>  }
>>
>> +/*
>> + * Rebase the __arena args of a kfunc call to arena kernel addresses,
>> + * rN = kern_vm_start + (u32)rN, with R12 holding kern_vm_start. A nullable
>> + * arg preserves NULL by skipping the add, tested on the truncated value as
>> + * arena NULL is offset 0. Return the number of emitted bytes.
>> + */
>> +static int emit_kfunc_arena_args(struct bpf_prog *bpf_prog,
>> +				 const struct bpf_insn *insn, u8 **pprog)
>> +{
>> +	const struct btf_func_model *fm;
>> +	u8 *prog = *pprog;
>> +	u8 *start = prog;
>> +	int i;
>> +
>> +	fm = bpf_jit_find_kfunc_model(bpf_prog, insn);
>> +	if (!fm)
>> +		return -EINVAL;
>> +
>> +	for (i = 0; i < min_t(int, fm->nr_args, MAX_BPF_FUNC_REG_ARGS); i++) {
>> +		u8 flags = fm->arg_flags[i];
>> +		u32 reg = BPF_REG_1 + i;
>> +
>> +		if (!(flags & BTF_FMODEL_ARENA_ARG))
>> +			continue;
>> +		if (WARN_ON_ONCE(!bpf_prog->aux->arena))
>> +			return -EINVAL;
>> +
>> +		/* mov eN, eN: truncate and clear the upper 32 bits */
>> +		emit_mov_reg(&prog, false, reg, reg);
>> +		if (flags & BTF_FMODEL_NULLABLE_ARG) {
>> +			/* test eN, eN; jz over the 3-byte add */
>> +			maybe_emit_mod(&prog, reg, reg, false);
>> +			EMIT2(0x85, add_2reg(0xC0, reg, reg));
>> +			EMIT2(X86_JE, 3);
>> +		}
>> +		/* add rN, r12 */
>> +		maybe_emit_mod(&prog, reg, X86_REG_R12, true);
>> +		EMIT2(0x01, add_2reg(0xC0, reg, X86_REG_R12));
>> +	}
>> +
>> +	*pprog = prog;
>> +	return prog - start;
>> +}
>
> In v1 review, Eduard Zingerman raised a concern about the JIT-based
> implementation approach, suggesting that it spreads complexity across
> multiple JITs (verifier.c + 6 jits) instead of keeping the bulk of the
> implementation in one place. He proposed an alternative using R0 by default
> with a jit_has_dedicated_arena_register() predicate to avoid the
> 64-immediate move overhead while centralizing the logic in verifier.c.
>
> Kumar responded that while this approach is reasonable for kfuncs, struct_ops
> would require uglier code with reloading/translating/storing. The v2 patch
> retained the JIT-based approach.
>

Yes, it was discussed offlist, we'll move ahead with JIT-based approach.

> [...]