Re: [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest

[Zhenzhong Wu]

Thanks for taking a look.

I used `r0 += 1` only to shift the helper success value from 0 to
1, so this test is not masked by the verifier's not-equal-zero
refinement. In this reproducer, `r0 += 1` does not enter the internal
BPF_ADD_CONST linked-scalar path.

The helper returns an integer with `R0 id=0`, `r0 += 1` keeps
`R0 id=0`, and the `r0`/`r7` scalar-id relation is established later
by the `r7 = r0` move on the failure path.

The success path skips that move and keeps `r7` independent. The test
is intended to cover pruning between those two different state shapes,
not ADD_CONST delta propagation.

Separately, I don't think the Fixes tag suggested by the bot is
appropriate. I do not have evidence that b0388bafa494 introduced this
issue. I can reproduce the issue on v5.10.258, v5.15.209, v6.1.91 and
v6.6.142. The upstream change that fixes this state shape is the later
linked-scalar precision tracking change:

  4bf79f9be434
  ("bpf: Track equal scalars history on per-instruction level")

More background is in the v2 thread:

  https://lore.kernel.org/r/20260607170959.823755-1-jt26wzz@xxxxxxxxx/

BR,
Zhenzhong

On Fri, Jun 12, 2026 at 12:58 AM <bot+bpf-ci@xxxxxxxxxx> wrote:
>
> > selftests/bpf: add helper retval linked scalar pruning selftest
> >
> >     Add a verifier runtime test for a branch pattern where a helper return
> >     value and a related scalar stay live across the same control-flow
> >     sequence. Rust/Aya-generated eBPF can naturally produce this shape when
> >     a match on a helper status keeps data derived before the helper call
> >     live across the same branches. Such code commonly uses the helper return
> >     value in r0, where 0 means success, producing an r0 == 0 / r0 != 0
> >     branch shape.
> >
> >     The test preserves that branch shape but shifts the success value to 1
> >     before branching. Using r0 == 1 / r0 != 1 avoids depending on the
> >     verifier's not-equal-zero refinement, so the test exercises linked
> >     scalar precision and pruning behavior directly instead of being masked
> >     by zero-specific range refinement.
> >
> >     On affected kernels the verifier can explore an impossible path where
> >     r0 and r7 are linked by scalar ID, keep the wrong branch, and make the
> >     test return 1. With linked scalar precision tracked per instruction,
> >     state pruning keeps the real success path, and the test returns 0.
> >
> >     Suggested-by: Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx>
> >     Signed-off-by: Zhenzhong Wu <jt26wzz@xxxxxxxxx>
>
> This adds a regression test for a verifier state-pruning issue with
> scalars linked by scalar ID, but there is no Fixes: tag.
>
> The test structure (success path keeps r7 independent with id=0, failure
> path links r7 to r0) matches the "registers with id=0 in cached state vs
> linked in current state" pruning scenario that was addressed by changing
> check_scalar_ids() and regsafe() to treat rold->id == 0 as independent.
>
> Should this carry:
>
>   Fixes: b0388bafa494 ("bpf: Relax scalar id equivalence for state pruning")
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27361218656