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

On Fri, Aug 21, 2026 at 1:54 PM Andrii Nakryiko
<[email protected]> wrote:
>
> 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://urldefense.com/v3/__https://lore.kernel.org/all/[email protected]/t/*m93ec917b3dfe3115be2a4b6439e2c649c791686d__;Iw!!BmdzS3_lV9HdKG8!zLLCzrdLf22D2nAvCY9zolVFNQrG3_TnvtoRIvm-HpwGPt9OIpIoC7q0ZWjijb396RLVMFi29c1j_DDBPPtC79aACUXBshO-eDCGtA$
> >
> > 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 ;)

Will add  the tag and more tests to cover it.
>
> 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".

Will do this cleanup.

I will be back with either the ready patchset or more questions as
soon as possible.

Thanks,
Andrey

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