Re: [PATCH bpf-next v4 10/14] bpf: change logging scheme for live stack analysis

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-05-11 at 19:45 +0200, Paul Chaignon wrote:

[...]

> > > I'm wondering if maybe there are other opportunities to reduce
> > > verbosity here (besides [1]). Maybe we don't need to print the
> > > fixed-point iterations if we're already printing the results? Or maybe
> > > we could put the more detailed liveness-related logs behind
> > > BPF_LOG_LEVEL3 or BPF_LOG_LIVENESS?
> > 
> > Had this been a normal compiler or jit engine, I'd vote for
> > BPF_LOG_LIVENESS log channel, I'm not sure what our stance regarding
> > user visible ABI here.
> 
> IIUC, it was only released in an RC and the logs themselves are not
> really part of the ABI, no? Or is there some other concern I'm missing?

I mean the valid flag values themselves. I hope log is not an ABI,
given the number of times we changed it. If BPF_LOG_LEVEL2 is considered
a kernel development only thing, then splitting it into multiple channels
would actually help the developer, imo.

> > Regarding BPF_LOG_LEVEL3, I think that the original idea behind
> > BPF_LOG_LEVEL2 is that it would serve as a "debug log" that regular
> > users won't need to consume. What is the motivation behind collecting
> > level 2 log on your CI? Is it to infer clues regarding programs
> > hitting 1M instructions limit?
> 
> At the moment, we collect this (1) in case of failures due to the 1M
> limit and (2) to compute the maximum combined stack depth using the
> per-subprog stack depths and the callgraph. (1) is not expected to be
> happening often and isn't much of an issue. For (2), I'm planning to
> send a patch to have the verifier report the max stack depth itself.
> 
> Overall, this isn't an issue for us. We're just using a bit more memory
> and disk space. I just though the sudden increase was unexpected and
> thought I'd have a look :)

For 1M instructions, I have the code to identify loop headers, so
error reporting here can be changed as follows:
- count the number of times each loop header is visited
- when 1M instructions limit is hit, identify the "hottest" loop
- print info about the loop
- if loop is supposed to converge (e.g. it is an iterator based loop)
  print out the samples from states cache, noting which registers
  differ between samples.

Alongside your future patch to printout stack depth this should make
log level 3 not needed for now, I think.

Kartikeya, do we plan to do something about 1M reporting or are we now
pivoting towards rust2bpf vision?