All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: <bot+bpf-ci@kernel.org>, <bpf@vger.kernel.org>
Cc: <andrii@kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>,
	<eddyz87@gmail.com>, <martin.lau@kernel.org>, <memxor@gmail.com>,
	<song@kernel.org>, <yonghong.song@linux.dev>, <yatsenko@meta.com>,
	<clm@meta.com>, <ihor.solodrai@linux.dev>
Subject: Re: [PATCH bpf-next v5 1/2] bpf: Only enforce 8 frame call stack limit for all-static stacks
Date: Wed, 11 Mar 2026 15:24:50 -0400	[thread overview]
Message-ID: <DH076DCNJOAO.20TLWKWHB5KUX@etsalapatis.com> (raw)
In-Reply-To: <5e8af34fe927be2c273db8459897fb1f29616b91e7b21f4430c9d414734f6a40@mail.kernel.org>

On Wed Mar 11, 2026 at 3:16 PM EDT, bot+bpf-ci wrote:
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 4fbacd2149cd..0304e4329490 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -6733,9 +6733,11 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,
>>  	struct bpf_insn *insn = env->prog->insnsi;
>>  	int depth = 0, frame = 0, i, subprog_end, subprog_depth;
>>  	bool tail_call_reachable = false;
>> -	int ret_insn[MAX_CALL_FRAMES];
>> -	int ret_prog[MAX_CALL_FRAMES];
>> -	int j;
>> +	int total;
>> +	int tmp;
>> +
>> +	/* no caller idx */
>> +	env->dinfo[idx].caller = -1;
>
> The function header comment above this hunk still reads:
>
>     Since recursion is prevented by check_cfg() this algorithm
>     only needs a local stack of MAX_CALL_FRAMES to remember callsites
>
> The local stack arrays (ret_insn[] and ret_prog[]) have been removed
> in favor of per-subprog dinfo fields. Should this comment be updated
> to reflect the new approach?
>
> This was also noted during the v3 and v4 reviews:
> https://lore.kernel.org/bpf/ad397307a9cd76c9739ee05f4642c7b6a881b7dfb8a2facefa6b2062ffe328ea@mail.kernel.org/
>
> [ ... ]
>
>> diff --git a/tools/testing/selftests/bpf/progs/test_global_func3.c b/tools/testing/selftests/bpf/progs/test_global_func3.c
>> index 142b682d3c2f..974fd8c19561 100644
>> --- a/tools/testing/selftests/bpf/progs/test_global_func3.c
>> +++ b/tools/testing/selftests/bpf/progs/test_global_func3.c
>
> [ ... ]
>
>>  SEC("tc")
>> -__failure __msg("the call stack of 8 frames")
>> +__failure __msg("the call stack of 9 frames")
>>  int global_func3(struct __sk_buff *skb)
>>  {
>>  	return f8(skb);
>
> Should this be "the call stack of 8 frames" rather than 9?
>
> The test has 9 subprogs total (global_func3 plus f1 through f8), but
> only 8 call levels. The entry function global_func3 starts at frame 0
> and is not itself counted by the frame increment. Each static call
> increments frame by one:
>
>     check_max_stack_depth_subprog() {
>         ...
>         frame = subprog_is_global(env, idx) ? 0 : frame + 1;
>         if (frame >= MAX_CALL_FRAMES) {
>             verbose(env, "the call stack of %d frames is too deep !\n",
>                 frame);
>
> With 8 static calls (global_func3 -> f8 -> f7 -> ... -> f1), frame
> reaches 8, which matches MAX_CALL_FRAMES. The verifier would print
> "the call stack of 8 frames is too deep" and the __msg substring
> check for "9 frames" would not match, causing the test to fail.
>
> The old test with global functions also had 8 call levels and
> expected "8 frames", since frame++ produced the same count of 8.
>

I'd say no to either suggestion. The updated expected failure message is
correct, and the old comment still applies for consecutive static stack
frames even if we don't refer to a single stack-allocated call stack anymore.

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


  reply	other threads:[~2026-03-11 19:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 18:28 [PATCH bpf-next v5 0/2] bpf: Relax 8 frame limitation for global subprogs Emil Tsalapatis
2026-03-11 18:28 ` [PATCH bpf-next v5 1/2] bpf: Only enforce 8 frame call stack limit for all-static stacks Emil Tsalapatis
2026-03-11 19:16   ` bot+bpf-ci
2026-03-11 19:24     ` Emil Tsalapatis [this message]
2026-03-14  2:40   ` Alexei Starovoitov
2026-03-16 15:09     ` Emil Tsalapatis
2026-03-11 18:28 ` [PATCH bpf-next v5 2/2] selftests/bpf: Add deep call stack selftests Emil Tsalapatis

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=DH076DCNJOAO.20TLWKWHB5KUX@etsalapatis.com \
    --to=emil@etsalapatis.com \
    --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=martin.lau@kernel.org \
    --cc=memxor@gmail.com \
    --cc=song@kernel.org \
    --cc=yatsenko@meta.com \
    --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 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.