From: Will Deacon <will@kernel•org>
To: Puranjay Mohan <puranjay12@gmail•com>
Cc: bpf@vger•kernel.org, Yonghong Song <yonghong.song@linux•dev>,
Alexei Starovoitov <ast@kernel•org>,
Daniel Borkmann <daniel@iogearbox•net>,
Andrii Nakryiko <andrii@kernel•org>,
Martin KaFai Lau <martin.lau@linux•dev>,
Eduard Zingerman <eddyz87@gmail•com>,
Kumar Kartikeya Dwivedi <memxor@gmail•com>,
Song Liu <song@kernel•org>, Xu Kuohai <xukuohai@huaweicloud•com>,
Catalin Marinas <catalin.marinas@arm•com>,
linux-arm-kernel@lists•infradead.org
Subject: Re: [PATCH bpf-next v2 2/3] bpf, arm64: Add JIT support for stack arguments
Date: Fri, 29 May 2026 14:36:13 +0100 [thread overview]
Message-ID: <ahmWTbYokwcp1Lel@willie-the-truck> (raw)
In-Reply-To: <CANk7y0j6JecSuJVZg1phn2tSHrcHPDqqmoaDBy1LdnMo-1qsFg@mail.gmail.com>
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
next prev parent reply other threads:[~2026-05-29 13:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 23:47 [PATCH bpf-next v2 0/3] bpf, arm64: Support stack arguments Puranjay Mohan
2026-04-27 23:47 ` [PATCH bpf-next v2 1/3] bpf, arm64: Map BPF_REG_0 to x8 instead of x7 Puranjay Mohan
2026-05-28 13:42 ` Will Deacon
2026-04-27 23:47 ` [PATCH bpf-next v2 2/3] bpf, arm64: Add JIT support for stack arguments Puranjay Mohan
2026-05-28 13:43 ` Will Deacon
2026-05-28 14:23 ` Puranjay Mohan
2026-05-29 13:36 ` Will Deacon [this message]
2026-04-27 23:48 ` [PATCH bpf-next v2 3/3] selftests/bpf: Enable stack argument tests for arm64 Puranjay Mohan
2026-05-28 13:42 ` Will Deacon
2026-05-28 14:29 ` Puranjay Mohan
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=ahmWTbYokwcp1Lel@willie-the-truck \
--to=will@kernel$(echo .)org \
--cc=andrii@kernel$(echo .)org \
--cc=ast@kernel$(echo .)org \
--cc=bpf@vger$(echo .)kernel.org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=eddyz87@gmail$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=martin.lau@linux$(echo .)dev \
--cc=memxor@gmail$(echo .)com \
--cc=puranjay12@gmail$(echo .)com \
--cc=song@kernel$(echo .)org \
--cc=xukuohai@huaweicloud$(echo .)com \
--cc=yonghong.song@linux$(echo .)dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox