[PATCH bpf-next v2 2/3] bpf, arm64: Add JIT support for stack arguments

[Will Deacon]

On Thu, May 28, 2026 at 03:23:32PM +0100, Puranjay Mohan wrote:
> Thanks for your review.
> These patches have already landed in bpf-next tree as a part of this
> series: https://lore.kernel.org/all/20260513044949.2382019-1-yonghong.song@linux.dev/
> 
> I will take all your feedback and send fixes for all the required changes.

Thanks. My review backlog is huge, but I still try to look at stuff even
after it's been merged.

> > How does that work with kfuncs? I think the PCS means that they will
> > expect to pick the stack arguments starting at [SP+0]. Or are you
> > saying that SP == FP+16 on entry to the callee? It's hard to reconcile
> > that with the ASCII art in build_prologue() because neither "current
> > A64_FP" nor "BPF_FP" point below A64_SP and it's not clear which of them
> > you're referring to when you refer to "FP" on its own.
> 
> At entry to kfunc the arguments are starting at [SP+0] like a normal C
> callee function would expect.
> 
> The line "callee reads them from [FP+16], [FP+24]" is for a BPF callee
> which always emits a frame record.
> So the caller puts the arguments at SP+0, SP+8, .. and then the callee
> creates the frame record in the prologue which means the first
> argument is at FP+16, ....
> This is just an implementation detail about how the JITed BPF callee
> programs can read stack arguments from FP+16, ... easily.

That makes sense, but if you're able to rejig the diagram in
build_prologue() to mirror that then it would really help us to remember
it in future.

> > > @@ -1191,6 +1207,41 @@ static int add_exception_handler(const struct bpf_insn *insn,
> > >       return 0;
> > >  }
> > >
> > > +static const u8 stack_arg_reg[] = { A64_R(5), A64_R(6), A64_R(7) };
> > > +
> > > +#define NR_STACK_ARG_REGS    ARRAY_SIZE(stack_arg_reg)
> > > +
> > > +static void emit_stack_arg_load(u8 dst, s16 bpf_off, struct jit_ctx *ctx)
> > > +{
> > > +     int idx = bpf_off / sizeof(u64) - 1;
> > > +
> > > +     if (idx < NR_STACK_ARG_REGS)
> > > +             emit(A64_MOV(1, dst, stack_arg_reg[idx]), ctx);
> > > +     else
> > > +             emit(A64_LDR64I(dst, A64_FP, (idx - NR_STACK_ARG_REGS) * sizeof(u64) + 16), ctx);
> > > +}
> >
> > Is it worth asserting that bpf_off >= 8 here or can we rely on that? I
> > struggled to find any details about how bpf passes arguments on the
> > stack (beyond what you describe in the commit message) and grepping for
> > BPF_REG_PARAMS didn't help either.
> 
> This and other patches in this set has more information about this:
> https://lore.kernel.org/all/20260513045015.2385013-1-yonghong.song@linux.dev/

Thanks, that matches what I'd managed to figure out.

Will