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

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2026-03-27 at 12:41 -0700, Barret Rhoden wrote:
> hi everyone -
>
> On 3/6/26 3:27 AM, Eduard Zingerman wrote:
> > On Fri, 2026-03-06 at 16:20 +0800, Levi Zim wrote:
>
> ...
>
> > > I have a BPF program [1] that is badly affected by the patch that it no
> > > longer loads on 6.19.5 due to
> > > E2BIG error.
> ...
>
> >
> > I'll take a detailed look tomorrow, but am curious if patch-set [1]
> > helps with your program? As far as I understand it is not a part of
> > 6.19, as it was not marked as "fixes".
> >
> > [1] https://lore.kernel.org/bpf/20251230-loop-stack-misc-pruning-v1-0-585cfd6cec51@gmail.com/
> >
> i'm in a similar situation - my scheduling program, which uses
> bpf_loop(), won't load with the dreaded E2BIG:
>
> 	processed 1000001 insns (limit 1000000) max_states_per_insn 76
> 	total_states 59608 peak_states 171016 mark_read 0
>
> i tried the patch at [1], and no luck there either.
>
> are there any tricks with this new SCC stuff to help with verification?

Hi Barret,

Is it possible for you to share the program code?
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.

It is hard to provide more specific advice w/o seeing the program
code.

Thanks,
Eduard

P.S.
  I know that loops handling is a major pita, we are working on a
  solution but it's a complex problem.