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

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Mon Aug 3, 2026 at 9:48 PM CEST, Andrii Nakryiko wrote:
> On Mon, Aug 3, 2026 at 12:27 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
>>
>> Currently, stack depth statistics are too crude, listing captured depths in
>> subprogram-number order. Since libbpf determines those numbers, it is hard 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 <andrii@kernel.org>
>> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>> ---
>>  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
>

The format makes sense, let me rework the output and parsing and repost a v5.

> [...]