Re: [PATCH bpf-next 06/18] bpf: Prepare architecture JIT support for stack arguments

bot+bpf-ci
2026-04-24T17:48:10Z

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index b77d0b06db6e..911205dd670e 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h

[ ... ]

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index cfb35a2decf6..fa4b971c5289 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c

[ ... ]

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index ec8523e6e4eb..7522b3d7b267 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c

[ ... ]

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index e041c182c614..0ba140dabe93 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12254,6 +12254,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> MAX_BPF_FUNC_REG_ARGS);
> return -EINVAL;
> }
> + if (nargs > MAX_BPF_FUNC_REG_ARGS && !bpf_jit_supports_stack_args()) {
> + verbose(env, "JIT does not support kfunc %s() with %d args\n",
> + func_name, nargs);
> + return -ENOTSUPP;
> + }

Can this new check ever execute? The existing check immediately above already
rejects all kfuncs with nargs > MAX_BPF_FUNC_REG_ARGS by returning -EINVAL.

Since control only reaches the new if statement when the previous check
passes, nargs must be <= MAX_BPF_FUNC_REG_ARGS. The condition
'nargs > MAX_BPF_FUNC_REG_ARGS' in the new check is therefore always false
at this point.

Looking at the commit message's statement "Reject BPF functions and kfuncs
with more than 5 parameters at verification time if the architecture does not
support stack arguments," it appears the intention was to conditionally reject
based on JIT support. However, for kfuncs, the unconditional rejection
happens first.

The btf_prepare_func_args() change does work as intended because its earlier
guards allow nargs up to MAX_BPF_FUNC_ARGS for certain subprogs before
reaching the stack-args check.

A later commit in this series (73a990fcc429) raises the first check in
check_kfunc_args() from MAX_BPF_FUNC_REG_ARGS to MAX_BPF_FUNC_ARGS, which
would make the new branch reachable. Should this hunk be combined with that
change to avoid introducing unreachable code?

---
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/24902767240