From: Menglong Dong <menglong.dong@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: menglong8.dong@gmail.com, andrii@kernel.org,
bot+bpf-ci@kernel.org, daniel@iogearbox.net,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, davem@davemloft.net, dsahern@kernel.org,
tglx@linutronix.de, mingo@redhat.com, jiang.biao@linux.dev,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, ast@kernel.org,
martin.lau@kernel.org, clm@meta.com, ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v11 02/12] bpf: use the least significant byte for the nr_args in trampoline
Date: Sat, 24 Jan 2026 09:14:04 +0800 [thread overview]
Message-ID: <2815478.mvXUDI8C0e@7950hx> (raw)
In-Reply-To: <CAEf4BzabUj0APqROb7ibkEovoXVmxbiHq0kNAPWExpEfRmQwiw@mail.gmail.com>
On 2026/1/24 06:57, Andrii Nakryiko wrote:
> On Fri, Jan 23, 2026 at 1:21 AM Menglong Dong <menglong.dong@linux.dev> wrote:
> >
> > On 2026/1/23 16:29 Menglong Dong <menglong.dong@linux.dev> write:
> > > On 2026/1/23 16:07 bot+bpf-ci@kernel.org write:
> > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > > index 41bbed6418b5..b3f912ad18ba 100644
> > > > > --- a/kernel/bpf/verifier.c
> > > > > +++ b/kernel/bpf/verifier.c
> > > >
> > > > [ ... ]
> > > >
> > > > > @@ -23779,12 +23781,13 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > > > > eatype == BPF_MODIFY_RETURN) {
> > > > > /* 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_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
> > > > > + insn_buf[1] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF);
> > > > > + insn_buf[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
> > > >
> > > > [ ... ]
> > > >
> > > > > - cnt = 6;
> > > > > + cnt = 7;
> > > > > } else {
> > > > > insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, -EOPNOTSUPP);
> > > > > cnt = 1;
> > > > > }
> > > > >
> > > > > new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
> > > >
> > > > [ ... ]
> > > >
> > > > > delta += cnt - 1;
> > > >
> > > > Note that the bpf_get_func_ret block above correctly updates delta after
> > > > patching.
> > > >
> > > > > @@ -23808,12 +23811,15 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > > > >
> > > > > /* skip 'void *__data' in btf_trace_##name() and save to reg0 */
> > > > > insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args - 1);
> > > > > + cnt = 1;
> > > > > } else {
> > > > > /* 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_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF);
> > > > > + cnt = 2;
> > > > > }
> > > > >
> > > > > - new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, 1);
> > > > > + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
> > > > > if (!new_prog)
> > > > > return -ENOMEM;
> > > > >
> > > > > env->prog = prog = new_prog;
> > > > > insn = new_prog->insnsi + i + delta;
> > > > > goto next_insn;
> > > > > }
> > > >
> > > > Should there be a "delta += cnt - 1;" before assigning env->prog in this
> > > > bpf_get_func_arg_cnt block? When cnt is 2 (non-RAW_TP path), the program
> > > > grows by one instruction, but delta is not updated. This could cause
> > > > subsequent bpf_patch_insn_data() calls to use incorrect offsets.
> > > >
> > > > The bpf_get_func_arg block at the beginning of this patch has:
> > > >
> > > > delta += cnt - 1;
> > > > env->prog = prog = new_prog;
> > > >
> > > > And the bpf_get_func_ret block similarly has delta updated. But this
> > > > bpf_get_func_arg_cnt block goes directly to env->prog assignment without
> > > > updating delta.
> > >
> > > Ah, good point, I think this is a valid problem. The selftests didn't cover
> > > this case, and I think I'd better to use bpf_get_func_arg() and bpf_get_func_ret()
> > > in the exit path of fsession to cover it.
> >
> > Oh, the problem doesn't have much impact. The only impact
> > is that the verifier will check the "r0 &= 0xFF" instruction redundantly.
> >
> > I'll see if there is more comment before I send next version.
> >
>
> Let's still fix the problem. Just go ahead and resubmit (with the fix
> and improved test).
OK!
>
> pw-bot: cr
>
>
> > Thanks!
> > Menglong Dong
> >
> > >
> > > Will fix it in the next version.
> > >
> > > Thanks!
> > > Menglong Dong
> > >
> > > >
> > > >
> > > > ---
> > > > AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> > > > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> > > >
> > > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21278745581
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
next prev parent reply other threads:[~2026-01-24 1:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 7:35 [PATCH bpf-next v11 00/12] bpf: fsession support Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 01/12] bpf: add " Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 02/12] bpf: use the least significant byte for the nr_args in trampoline Menglong Dong
2026-01-23 8:07 ` bot+bpf-ci
2026-01-23 8:29 ` Menglong Dong
2026-01-23 9:21 ` Menglong Dong
2026-01-23 22:57 ` Andrii Nakryiko
2026-01-24 1:14 ` Menglong Dong [this message]
2026-01-23 7:35 ` [PATCH bpf-next v11 03/12] bpf: change prototype of bpf_session_{cookie,is_return} Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 04/12] bpf: support fsession for bpf_session_is_return Menglong Dong
2026-01-23 8:07 ` bot+bpf-ci
2026-01-23 8:15 ` Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 05/12] bpf: support fsession for bpf_session_cookie Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 06/12] bpf,x86: introduce emit_store_stack_imm64() for trampoline Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 07/12] bpf,x86: add fsession support for x86_64 Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 08/12] libbpf: add fsession support Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 09/12] bpftool: " Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 10/12] selftests/bpf: add testcases for fsession Menglong Dong
2026-01-23 7:57 ` bot+bpf-ci
2026-01-23 8:05 ` Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 11/12] selftests/bpf: add testcases for fsession cookie Menglong Dong
2026-01-23 7:35 ` [PATCH bpf-next v11 12/12] selftests/bpf: test fsession mixed with fentry and fexit Menglong Dong
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=2815478.mvXUDI8C0e@7950hx \
--to=menglong.dong@linux.dev \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hpa@zytor.com \
--cc=ihor.solodrai@linux.dev \
--cc=jiang.biao@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=menglong8.dong@gmail.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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