Re: [PATCH bpf-next v4 1/3] bpf: Show more useful info in stack depth stats

On Mon, Aug 3, 2026 at 12:27=E2=80=AFAM Kumar Kartikeya Dwivedi
<[email protected]> wrote:
>
> Currently, stack depth statistics are too crude, listing captured depths =
in
> subprogram-number order. Since libbpf determines those numbers, it is har=
d to
> associate each depth with its subprogram name.
>
> Print the maximum stack depth and each subprogram on separate lines:
>
> stack depth max <depth>
> stack depth subprog <number> <name> <depth>
>
> When no subprogram name is available, print <unknown>.
>
> Suggested-by: Andrii Nakryiko <[email protected]>
> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]>
> ---
>  kernel/bpf/verifier.c                         | 13 +++++++----
>  .../bpf/progs/verifier_basic_stack.c          |  4 ++--
>  .../bpf/progs/verifier_bpf_fastcall.c         | 23 ++++++++++++-------
>  .../bpf/progs/verifier_private_stack.c        | 15 +++++++++---
>  .../selftests/bpf/progs/verifier_var_off.c    |  4 ++--
>  5 files changed, 40 insertions(+), 19 deletions(-)
>

given we are going for quite verbose one line per prog/subprog format
anyways, let's make it actually even more useful and emit
insns_processed as well? I'd probably keep total line (processed N
insns (limit 1000000) ...) for backwards compat, but also have
per-subprog + main prog line with insns stat and stack depth,
something like

subprog 1 (sub1) insns 123 stack 16
subprog 2 (sub2) insns 345 stack 32
prog (main_one) insns 643 stack 64
processed 9999 insns (limit 1000000) max_states_per_insn 0
total_states 1 peak_states 1 mark_read 0

wdyt?

this will give better and more targeted information on where you
should look for w.r.t. verification optimization opportunities

and we can later add some other useful stats per-subprog/main prog as
necessary without any major breakage (tool just need to assume there
might be more stuff after "stack N" eventually

[...]