Re: [External] [PATCH bpf-next v2 1/2] libbpf: Introduce bpf_program__clone()

On Mon, Aug 17, 2026 at 8:32 AM Andrey Grodzovsky
<[email protected]> wrote:
>
> > > > Hey Andrii, getting back to this important topic -
> > > >
> > > > I reviewed the proposed solution and the code . An object-wide
> > > > bpf_object_open_opts flag that means "all programs must be
> > > > considered loadable, but maybe later" collapses two things that need
> > > > to stay separate: a program that is not currently loaded but may load
> > > > later (feature gated, config-driven), and a program that is
> > > > permanently not going to load on this object instance (e.g. it
> > > > targets a kernel symbol/struct field that doesn't exist on the running
> > > > kernel, or it lost out to an equivalent alternative implementation and
> > > > will never be used). Today those are distinguished by the autoload
> > > > bool: false + never load = the second case. If the semantics of "not
> > > > autoloaded" change object-wide to "loadable later," we lose the
> > > > ability to express the second case at all -- every non-autoloaded
> > > > program in the object now implicitly carries the cost and risk of
> > > > being treated as eventually loadable, even the ones that never will
> > > > be. So, every non-autoloaded program is implicitly pulled into
> > > > relocation resolution and map creation, since nothing can rule out
> > > > that it might load. For a program that  never will, that's
> > > > wasted preprocessing, and if its relocations fail against this
> > > > kernel's BTF, that failure is no longer isolated to just that program.
> > > >
> > > > Given this I wonder if it's reasonable to re-evaluate the approach of
> > > > per-program enum from the original patch series we prosposed , rather than a
> > > > boolean plus an object-wide opt-in flag. Keeping disabled as its own
> > > > per-program state (excluded from relocation and map-creation, failures
> > > > isolated) alongside auto and the new dynamic case state gets us
> > > > the capabilities we want without forcing every already-
> > > > disabled program in an object to be reclassified as "maybe loadable.
> > > >
> > >
> > > Goodness, 4 month since that discussion... I don't remember all the
> > > details, we can start a new conversation and go over details, but I'm
> > > just about to leave for vacation and Mykyta is still out on vacation,
> > > so I'd suggest to restart this conversation with all the details anew
> > > in about a month of so, if that's ok?
> >
> > Defenetly! So just to clarify, per your advice from earlier in this thread,
> > we don't plan to rely on the cloned sessions concept anymore and suggest
> > instead to review again the approach we proposed initially [1].
> >
> > >
> > > Explicit tri-state per program vs implicit tri-state (if not
> > > explicitly disabled -> maybe enabled, if per-object setting is set) is
> > > probably not the most blocking part of this. But again, let's come
> > > back to this with fresh heads :)
> >
> > We will gladly review it again and adapt it so that it is acceptable
> > to the community and can be
> > beneficial to all users of libbpf.
> >
> > I will reach out again in the second half of August.
> >
> > Thans,
> > Andrey
> >
> > [1] -https://lore.kernel.org/all/[email protected]/t/#m93ec917b3dfe3115be2a4b6439e2c649c791686d
>
> Hi Andrii,
>
> Following up as promised from our discussion last month regarding
> dynamic program loading.
>
> I reviewed our initial patchset and the subsequent mailing list
> thread. It seems the conversation previously veered into unrelated
> topics, such as concurrent programs loading and dynamic map loading,
> which are beyond the scope of the dynamic program loading capability
> we are trying to introduce.
>
> To recap our main point from July, using a global object-wide flag
> collapses two distinct states: programs that are genuinely disabled
> (e.g., due to missing kernel symbols, where we want failure isolation)
> and programs intended for late, dynamic loading. If we use a
> per-object setting, every non-autoloaded program is forced into
> relocation resolution, potentially causing load failure and wasting
> preprocessing time.
>
> If that is ok with you, I would like to resend the original two-patch
> series as an RFC with a cover letter, rebased and retested against the
> latest bpf-next branch. This way we can review and discuss the
> approach from a clean slate.
>

yes, let's start with resending patches (you can drop RFC, otherwise
CI testing story is worse) and let's go from there.

I'm actually wondering, if we are going to introduce a their auto-load
state from current true/false, whether we should also have a new SEC()
naming convention for such programs so that one can declaratively
specify that this program *might* be loaded after object load, and as
such should go through a proper relocation and other manipulations.
I.e., we have SEC("raw_tp/...") for eager load, SEC("?raw_tp/...") for
default no-load, perhaps we have to add SEC("!raw_tp/...") (or some
other appropriate prefix) for lazy-load programs?

And actually (I won't erase the above, but it just occurred to me)
nowadays perhaps decl_tag is the better way to go. Can you experiment
with this? We can bikeshed on naming later ;)

For bpf_program__set_autoload() API, I *think* we can manage backwards
compatibility by converting bool argument to enum with zero matching
to "don't load", 1 matching to "eagerly load" and 2 will be "lazy load
maybe later if user ask for it".

> Thanks,
> Andrey
> >
> >
> >
> > >
> > >
> > > > Thanks!
> > > > Andrey
> > > > >
> > > > >
> > >
> > > [...]