From: Yonghong Song <yonghong.song@linux.dev>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
jose.marchesi@oracle.com, kernel-team@fb.com,
martin.lau@kernel.org, eddyz87@gmail.com, clm@meta.com,
ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v5 11/16] bpf: Support stack arguments for kfunc calls
Date: Sat, 18 Apr 2026 10:57:01 -0700 [thread overview]
Message-ID: <bb1a896a-bc92-42a7-9019-017aa77b6b7e@linux.dev> (raw)
In-Reply-To: <e5a6e801c10994cc2e03b0cd57e76152eb234493a6b7395a9859feade4a6575b@mail.kernel.org>
On 4/16/26 9:43 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
> [ ... ]
>
>> @@ -20145,6 +20209,16 @@ int bpf_fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>> if (!bpf_jit_supports_far_kfunc_call())
>> insn->imm = BPF_CALL_IMM(desc->addr);
>>
>> + /*
>> + * After resolving the kfunc address, insn->off is no longer needed
>> + * for BTF fd index. Repurpose it to store the number of stack args
>> + * so the JIT can marshal them.
>> + */
>> + if (desc->func_model.nr_args > MAX_BPF_FUNC_REG_ARGS)
>> + insn->off = desc->func_model.nr_args - MAX_BPF_FUNC_REG_ARGS;
>> + else
>> + insn->off = 0;
>> +
> Is insn->off really "no longer needed for BTF fd index" after this
> point? Looking at bpf_jit_find_kfunc_model() in kernel/bpf/fixups.c,
> the function is called during JIT compilation from every BPF JIT backend
> that supports kfunc calls (x86_32, s390, riscv64, ppc64, loongarch).
>
> It performs a bsearch on the kfunc_tab keyed by (insn->imm, insn->off)
> using kfunc_desc_cmp_by_imm_off:
>
> kernel/bpf/fixups.c:kfunc_desc_cmp_by_imm_off() {
> ...
> if (a->imm != b->imm)
> return a->imm < b->imm ? -1 : 1;
> if (a->offset != b->offset)
> return a->offset < b->offset ? -1 : 1;
> return 0;
> }
>
> The desc->offset was populated from the original insn->off during
> bpf_add_kfunc_call(), where for module kfuncs it is a non-zero BTF fd
> index.
>
> The call order is:
>
> bpf_check()
> -> bpf_do_misc_fixups()
> -> bpf_fixup_kfunc_call() (overwrites insn->off to 0 or stack_arg_count)
> -> bpf_prog_select_runtime()
> -> bpf_int_jit_compile()
> -> arch JIT
> -> bpf_jit_find_kfunc_model() (reads insn->off for bsearch key)
>
> After this patch, for a kfunc with 5 or fewer args that lives in a
> module (non-zero btf_fd_idx), insn->off is zeroed, and the bsearch will
> fail to find the entry that was stored with offset=btf_fd_idx.
>
> For kfuncs with more than 5 args, the new value of insn->off (stack arg
> count) also will not match desc->offset (btf_fd_idx or 0), so module
> kfuncs with stack args are also broken, and vmlinux kfuncs with more
> than 5 args get a nonzero insn->off that no longer matches
> desc->offset=0.
>
> Can the stack arg count be communicated to the JIT without clobbering
> the btf_fd_idx that bsearch still keys on?
The above code is dead code. Will remove.
>
>
> ---
> 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/24546989054
next prev parent reply other threads:[~2026-04-18 17:57 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 3:46 [PATCH bpf-next v5 00/16] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 01/16] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 02/16] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 03/16] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-17 4:49 ` sashiko-bot
2026-04-18 16:40 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 16:47 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 04/16] bpf: Prepare verifier logs for upcoming kfunc stack arguments Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 05/16] bpf: Introduce bpf register BPF_REG_PARAMS Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 06/16] bpf: Limit the scope of BPF_REG_PARAMS usage Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 16:48 ` Yonghong Song
2026-04-17 4:50 ` sashiko-bot
2026-04-18 16:50 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-18 16:54 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 07/16] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 17:00 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 17:03 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 08/16] bpf: Support stack arguments for bpf functions Yonghong Song
2026-04-17 4:35 ` sashiko-bot
2026-04-18 17:10 ` Yonghong Song
2026-04-17 4:43 ` bot+bpf-ci
2026-04-18 17:11 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-17 3:47 ` [PATCH bpf-next v5 09/16] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 17:17 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-17 3:47 ` [PATCH bpf-next v5 10/16] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-04-17 4:08 ` sashiko-bot
2026-04-18 17:18 ` Yonghong Song
2026-04-18 17:37 ` Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 1:04 ` bot+bpf-ci
2026-04-18 17:24 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 11/16] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-04-17 4:40 ` sashiko-bot
2026-04-18 17:46 ` Yonghong Song
2026-04-17 4:43 ` bot+bpf-ci
2026-04-18 17:57 ` Yonghong Song [this message]
2026-04-18 1:04 ` bot+bpf-ci
2026-04-18 18:04 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 12/16] bpf: Enable stack argument support for x86_64 Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-17 5:03 ` sashiko-bot
2026-04-18 18:07 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-17 3:48 ` [PATCH bpf-next v5 13/16] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-04-17 4:44 ` sashiko-bot
2026-04-18 16:43 ` Puranjay Mohan
2026-04-18 18:15 ` Yonghong Song
2026-04-18 1:20 ` bot+bpf-ci
2026-04-18 18:23 ` Yonghong Song
2026-04-17 3:48 ` [PATCH bpf-next v5 14/16] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-04-17 4:20 ` sashiko-bot
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 18:26 ` Yonghong Song
2026-04-17 3:48 ` [PATCH bpf-next v5 15/16] selftests/bpf: Add negative test for greater-than-8-byte kfunc stack argument Yonghong Song
2026-04-17 4:28 ` sashiko-bot
2026-04-18 18:29 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-17 3:48 ` [PATCH bpf-next v5 16/16] selftests/bpf: Add verifier tests for stack argument validation Yonghong Song
2026-04-17 4:38 ` sashiko-bot
2026-04-18 18:36 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 16:39 ` [PATCH bpf-next v5 00/16] bpf: Support stack arguments for BPF functions and kfuncs Puranjay Mohan
2026-04-18 18:47 ` Alexei Starovoitov
2026-04-18 18:54 ` Yonghong Song
2026-04-18 17:06 ` 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=bb1a896a-bc92-42a7-9019-017aa77b6b7e@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=jose.marchesi@oracle.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.