Re: [PATCH 0/2] bpf: calls to bpf_loop() should have an SCC and accumulate backedges

[Barret Rhoden <brho@google.com>]

On 3/27/26 4:10 PM, Eduard Zingerman wrote:?
> If not, here are a few generic tips:
> - If there is bpf_for or bpf_loop based loop and you hit 1M
>    instructions limit, this means that internal loop state does not
>    converge to some previously visited state from verifier point of
>    view.
> - Most likely there is a pattern like this:
> 
>      v = 0;                            v = 0;
>      bpf_for(i, ...) {                 bpf_for(i, ...) {
>        ...                               ...
>        v += 1;                - or -     v += 1;
>      }                                   use v for memory access
>      use v for memory access.          }
> 
>    Or its equivalent in bpf_loop terms.
>    'v' might also be a pointer incremented inside a loop.
>    Unfortunately, we don't have a simple way to identify which variable
>    is a culprit. We do have a way to identify which loop fails to converge:
>    the 'veristat' tool executed with --top-src-lines=N option will
>    print out C lines corresponding to instructions that verifier
>    visited most-often before giving up.
> - There are several possible remedies for the pattern above:
>    - hide exact value of 'v' from verifier by initializing
>      it using a global, see tools/testing/selftests/bpf/progs/arena_htab.c
>      variable 'zero'.
>    - change the logic to rely on 'i' instead of 'v',
>      for 'i' verifier does not know exact value, but knows its range.
> - Another generic advice is to split program into global subprograms.
>    Global subprograms called from the loop body won't inflate the callers
>    verification budget.

great tips, thanks!  i opted for the global function one; it's a common 
sledgehammer in my "fight the verifier" toolkit.  =)

the loop function was calling a very large function, so that was 
probably the right tool for the job.  next time i'll take a look at 
veristat.

thanks,

barret