[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2336927.iZASKD2KPV@7940hx>
Date: Wed, 14 Jan 2026 10:19:02 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Menglong Dong <menglong8.dong@...il.com>,
Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: ast@...nel.org, andrii@...nel.org, daniel@...earbox.net,
martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, davem@...emloft.net,
dsahern@...nel.org, tglx@...utronix.de, mingo@...hat.com,
jiang.biao@...ux.dev, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, bpf@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject:
Re: [PATCH bpf-next v9 02/11] bpf: use last 8-bits for the nr_args in
trampoline
On 2026/1/14 09:22 Andrii Nakryiko <andrii.nakryiko@...il.com> write:
> On Sat, Jan 10, 2026 at 6:11 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> >
> > For now, ctx[-1] is used to store the nr_args in the trampoline. However,
> > 1-byte is enough to store such information. Therefore, we use only the
> > last byte of ctx[-1] to store the nr_args, and reserve the rest for other
>
> Looking at the assembly below I think you are extracting the least
> significant byte, right? I'd definitely not call it "last" byte...
> Let's be precise and unambiguous here.
Yeah, the "last 8-bits", "lat byte" is ambiguous. So let's describe it as
"the least significant byte" here instead :)
Thanks!
Menglong Dong
>
> > usages.
> >
> > Signed-off-by: Menglong Dong <dongml2@...natelecom.cn>
> > ---
> > v8:
> > - fix the missed get_func_arg_cnt
> > ---
> > kernel/bpf/verifier.c | 35 +++++++++++++++++++----------------
> > kernel/trace/bpf_trace.c | 6 +++---
> > 2 files changed, 22 insertions(+), 19 deletions(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 774c9b0aafa3..bfff3f84fd91 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -23277,15 +23277,16 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > insn->imm == BPF_FUNC_get_func_arg) {
> > /* Load nr_args from ctx - 8 */
> > insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > - insn_buf[1] = BPF_JMP32_REG(BPF_JGE, BPF_REG_2, BPF_REG_0, 6);
> > - insn_buf[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 3);
> > - insn_buf[3] = BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_1);
> > - insn_buf[4] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_2, 0);
> > - insn_buf[5] = BPF_STX_MEM(BPF_DW, BPF_REG_3, BPF_REG_0, 0);
> > - insn_buf[6] = BPF_MOV64_IMM(BPF_REG_0, 0);
> > - insn_buf[7] = BPF_JMP_A(1);
> > - insn_buf[8] = BPF_MOV64_IMM(BPF_REG_0, -EINVAL);
> > - cnt = 9;
> > + insn_buf[1] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF);
> > + insn_buf[2] = BPF_JMP32_REG(BPF_JGE, BPF_REG_2, BPF_REG_0, 6);
> > + insn_buf[3] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 3);
> > + insn_buf[4] = BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_1);
> > + insn_buf[5] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_2, 0);
> > + insn_buf[6] = BPF_STX_MEM(BPF_DW, BPF_REG_3, BPF_REG_0, 0);
> > + insn_buf[7] = BPF_MOV64_IMM(BPF_REG_0, 0);
> > + insn_buf[8] = BPF_JMP_A(1);
> > + insn_buf[9] = BPF_MOV64_IMM(BPF_REG_0, -EINVAL);
> > + cnt = 10;
> >
>
> [...]
>
Powered by blists - more mailing lists