Re: [PATCH bpf-next v5 10/16] bpf: Reject stack arguments if tail call reachable

bot+bpf-ci
2026-04-17T04:30:10Z

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

> commit b77ef401ea17eab379f390ca5d89aeab4b271ca7
> Author: Yonghong Song <yonghong.song@linux.dev>
> Date: Thu Apr 16 20:47:49 2026 -0700
>
> bpf: Reject stack arguments if tail call reachable
>
> Tailcalls are been deprecated. So reject stack arguments
> if tail call is in the way.

The commit message has a grammatical error: "Tailcalls are been deprecated"
should be either "have been" or "are being".

Also, is the claim that tail calls are deprecated accurate? Based on earlier
mailing list discussion, the restriction exists because tail calls and stack
arguments require incompatible stack frame handling, not because tail calls
are being deprecated. Could the commit message be more precise about the
actual technical reason for the restriction?

This also appears to be a bug fix for the stack arguments feature. Should
this include a Fixes tag for the original stack arguments commit?

Suggested: Fixes: 21229535935384b01e3cef3c117233b23b2f3902 ("bpf: Support
stack arguments for bpf functions")

>
> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7a65b532e84a..739c3127520c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5662,6 +5662,11 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,
> verbose(env, "cannot tail call within exception cb\n");
> return -EINVAL;
> }
> + if (subprog[tmp].incoming_stack_arg_depth ||
> + subprog[tmp].outgoing_stack_arg_depth) {
> + verbose(env, "tail_calls are not allowed in programs with stack args\n");
> + return -EINVAL;
> + }
> subprog[tmp].tail_call_reachable = true;
> }
> if (subprog[0].tail_call_reachable)

When the traversal pops a frame to return to the caller and jumps back to
continue_func, is the tail_call_reachable variable reset to false?

Looking at the broader context of check_max_stack_depth_subprog(), after
processing a callee, the code pops back to the caller:

/* pop caller idx from callee */
idx = dinfo[idx].caller;
...
goto continue_func;

If the verifier traverses a subprogram with a tail call, returns, and then
traverses a completely unrelated sibling subprogram that uses stack
arguments, would it incorrectly evaluate tail_call_reachable as true and
reject the valid sibling?

Is there a state leak in this DFS traversal that could cause false positive
rejections of valid BPF programs?

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