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 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.