[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <d91544bd4b513290bf468386c0261f913b59b761c34405839c424f8eaf8b1d04@mail.kernel.org>
Date: Fri, 23 Jan 2026 08:07:45 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: menglong8.dong@...il.com,andrii@...nel.org
Cc: 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,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v11 02/12] bpf: use the least significant byte for the nr_args in trampoline
> 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.
---
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
Powered by blists - more mailing lists