Re: [PATCH bpf-next] verifier: add prune points to live registers print

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2025-12-23 at 11:12 +0100, Mahe Tardy wrote:
> On Mon, Dec 22, 2025 at 08:32:57PM -1000, Alexei Starovoitov wrote:
> > On Mon, Dec 22, 2025 at 8:58 AM Mahe Tardy <mahe.tardy@gmail.com> wrote:
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index d6b8a77fbe3b..a82702405c12 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -24892,7 +24892,7 @@ static int compute_live_registers(struct bpf_verifier_env *env)
> > >                 insn_aux[i].live_regs_before = state[i].in;
> > > 
> > >         if (env->log.level & BPF_LOG_LEVEL2) {
> > > -               verbose(env, "Live regs before insn:\n");
> > > +               verbose(env, "Live regs before insn, pruning points (p), and force checkpoints (P):\n");
> > >                 for (i = 0; i < insn_cnt; ++i) {
> > >                         if (env->insn_aux_data[i].scc)
> > >                                 verbose(env, "%3d ", env->insn_aux_data[i].scc);
> > > @@ -24904,7 +24904,12 @@ static int compute_live_registers(struct bpf_verifier_env *env)
> > >                                         verbose(env, "%d", j);
> > >                                 else
> > >                                         verbose(env, ".");
> > > -                       verbose(env, " ");
> > > +                       if (is_force_checkpoint(env, i))
> > > +                               verbose(env, " P ");
> > > +                       else if (is_prune_point(env, i))
> > > +                               verbose(env, " p ");
> > > +                       else
> > > +                               verbose(env, "   ");
> > 
> > tbh I don't quite see the value. I never needed to know
> > the exact pruning points while working on the verifier.
> > It has to work with existing pruning heuristics and with
> > BPF_F_TEST_STATE_FREQ. So pruning points shouldn't matter
> > to the verifier algorithms. If they are we have a bigger problem
> > to solve than show them in the verifier log to users
> > who won't be able to make much sense of them.
> 
> Yeah I think we would agree with Paul on that. And as you mention, with
> the addition of the heuristics on top of prune points, it would maybe be
> more useful to know when the verifier actually saves a new state (but
> that would increase log verbosity).
> 
> > It's my .02. If other folks feel that it's definitely
> > useful we can introduce this extra verbosity,
> > but all the churn in the selftests is another indication
> > of a feature that "nice, but..."
> 
> Tbh that's also when I realized that indeed it was "nice, but..." since
> because of those changes, all those liveness tests would depend on the
> position of prune points. 
> 
> At the same time, the new print would allow us to write a series of
> tests to check for all the possible cases of prune points as presented
> in the talk, not sure it's actually useful as well...

Hi Everyone,

Sorry, a bit late to the discussion, here are another .02 cents.
Tbh, I'm neither for nor against printing these marks.
Knowing where exactly the checkpoints are is helpful to me sometimes
when I'd like to construct a specific test. On the other hand,
I can always add debug prints locally + you do learn the rules for
checkpoints after some time.  If we go for it, we should probably
distinguish between prune points and "force checkpoints" ('f'?).

Imo, it would be indeed more interesting to print where checkpoint
match had been attempted and why it failed, e.g. as I do in [1].
Here is a sample:

  cache miss at (140, 5389): frame=1, reg=0, spi=-1, loop=0 (cur: 1) vs (old: P0)
  from 5387 to 5389: frame1: R0=1 R1=0xffffffff ...

However, in the current form it slows down log level 2 output
significantly (~5 times). Okay for my debugging purposes but is not
good for upstream submission.

Thanks,
Eduard.

[1] https://github.com/kernel-patches/bpf/commit/65fcd66d03ad9d6979df79628e569b90563d5368