Re: [PATCH bpf-next v2 2/2] selftests/bpf: Use bpf_program__clone() in veristat

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-02-24 at 19:12 +0000, Mykyta Yatsenko wrote:
> On 2/24/26 19:08, Eduard Zingerman wrote:
> > On Tue, 2026-02-24 at 12:20 +0000, Mykyta Yatsenko wrote:
> > 
> > [...]
> > 
> > > > I run selftests binaries through old and new veristat versions and see
> > > > some discrepancies. csv files attached.
> > > > It looks like there are some failures that are now not logged.
> > > > There is also at-least one success -> failure transition and
> > > > a bunch of failure -> success transitions.
> > > > I see no such differences for sched_ext programs.
> > > > Is this an expected behavior?
> > > yes, the regressions are explained in the cover letter:
> > > """
> > > Known regression:
> > > - Program-containing maps (PROG_ARRAY, DEVMAP, CPUMAP) track
> > > owner program type. Programs with incompatible attributes
> > > loaded against a shared map will be rejected. This is
> > > expected kernel behavior.
> > > """
> > > in the previous version of this series, there were no regressions,
> > > but to achieve that we had to be a little bit creative with maps
> > > loading, have a look:
> > > https://lore.kernel.org/all/20260212-veristat_prepare-v1-1-c351023fb0db@meta.com/
> > > clone_prog_maps()
> > > 
> > > The improvements are explained in the sibling thread with Alexei
> > > (again because of PROG_ARRAY type of maps)
> > Are you sure that's what happens?
> > Looking at 'failure -> N/A' transitions, it appears that this is
> > caused by the early exit from process_obj() if bpf_object__prepare() fails.
> > Previously each program in the object failing the __prepare() was
> > reported as 'failed', now these are skipped entirely.
> > I think it would be nice to have an additional logic in process_obj()
> > marking programs as failed if __prepare() fails.
> Ah, you mean those ones, I don't consider these regressions,
> because they failed in the base version anyways. I discussed this case
> with Andrii:
> https://lore.kernel.org/all/7990bafe-d72c-47de-a711-0c8a888d4ed9@gmail.com/
> 
> What I was talking is the case where it goes from
> success to failure with these changes.

I think this part is worth doing:

  > If we really need to be on par, I can iterate over progs if 
  > bpf_object__prepare()
  > fails, it just looks a bit awkward.

Because otherwise these programs would be completely invisible in the
csv output.