From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Emil Tsalapatis <emil@etsalapatis.com>,
kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v6 2/6] bpf: Propagate async callback instructions to scheduling subprograms
Date: Wed, 05 Aug 2026 11:18:21 -0700 [thread overview]
Message-ID: <952a9aa9e0e8d0e8bbcf54dda79b1b88ff48e1ff.camel@gmail.com> (raw)
In-Reply-To: <20260805011517.1717238-3-memxor@gmail.com>
On Wed, 2026-08-05 at 03:15 +0200, Kumar Kartikeya Dwivedi wrote:
...
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 9de45ade473b..42fa464c520f 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -447,6 +447,8 @@ static_assert(MAX_BPF_STACK / 8 <= (1 << 6));
> struct bpf_verifier_state {
> /* call stack tracking */
> struct bpf_func_state *frame[MAX_CALL_FRAMES];
> + u32 async_stats_subprog_ids[MAX_CALL_FRAMES];
> + u32 async_stats_subprog_cnt;
One async callback can call another async callback, e.g. see program
'test1' in progs/timer.c. Meaning that this array is not really bound
by MAX_CALL_FRAMES and the code below may overflow it.
Overall, it seems that having an alternative full call stack solely
for the purpose of accounting is an overkill. I'd just show async
subprograms as their own roots, tbh. On the other hand, same
subprogram can be called both as an async and as a regular subprogram :)
so the idea of a separate spine is not w/o it's merit.
If we decide to stick with it, maybe pick a better name?
'verification_call_stack' or something like this?
If we decide to go with this separate call stack, would it be possible
to adapt the code in a way that only this call stack is used for
accounting? (e.g. is filled on regular subprogram calls etc).
Another option is to build an implicit call graph in env while
verifying and count only self instructions and counters on edges.
Then propagate the data over the graph in post-order traversal
(subprog_topo_order is already computed). I think I like this idea
the most.
...
> @@ -2293,6 +2298,12 @@ static struct bpf_verifier_state *push_async_cb(struct bpf_verifier_env *env,
> 0 /* frameno within this callchain */,
> subprog /* subprog number within this prog */);
> elem->st.frame[0] = frame;
> + cnt = env->cur_state->async_stats_subprog_cnt;
> + memcpy(elem->st.async_stats_subprog_ids, env->cur_state->async_stats_subprog_ids,
> + cnt * sizeof(elem->st.async_stats_subprog_ids[0]));
> + for (i = 0; i <= env->cur_state->curframe; i++)
> + elem->st.async_stats_subprog_ids[cnt++] = env->cur_state->frame[i]->subprogno;
> + elem->st.async_stats_subprog_cnt = cnt;
> return &elem->st;
> }
...
next prev parent reply other threads:[~2026-08-05 18:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 1:15 [PATCH bpf-next v6 0/6] Improve stack depth verification stats output Kumar Kartikeya Dwivedi
2026-08-05 1:15 ` [PATCH bpf-next v6 1/6] bpf: Track verifier instruction stats for each subprogram Kumar Kartikeya Dwivedi
2026-08-05 1:26 ` sashiko-bot
2026-08-05 1:15 ` [PATCH bpf-next v6 2/6] bpf: Propagate async callback instructions to scheduling subprograms Kumar Kartikeya Dwivedi
2026-08-05 1:40 ` sashiko-bot
2026-08-05 18:18 ` Eduard Zingerman [this message]
2026-08-05 1:15 ` [PATCH bpf-next v6 3/6] bpf: Show more useful info in stack depth stats Kumar Kartikeya Dwivedi
2026-08-05 1:28 ` sashiko-bot
2026-08-05 1:15 ` [PATCH bpf-next v6 4/6] selftests/bpf: Adjust veristat stack depth parsing Kumar Kartikeya Dwivedi
2026-08-05 1:15 ` [PATCH bpf-next v6 5/6] selftests/bpf: Test stack depth stats without BTF subprog names Kumar Kartikeya Dwivedi
2026-08-05 1:15 ` [PATCH bpf-next v6 6/6] selftests/bpf: Test subprogram instruction statistics Kumar Kartikeya Dwivedi
2026-08-05 1:23 ` sashiko-bot
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=952a9aa9e0e8d0e8bbcf54dda79b1b88ff48e1ff.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
--cc=memxor@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox