Re: libbpf API: dynamically load(/unload/attach/detach) bpf programs question

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Tue, Jan 11, 2022 at 4:33 AM Yaniv Agman <yanivagman@gmail.com> wrote:
>
> Hello!
>
> I noticed that the bpf_program__load() API was deprecated since libbpf
> 0.6 saying that bpf_object__load() should be used instead.
> This, however, doesn't seem to fit our use case of loading multiple
> bpf programs (that also share the same maps) from one bpf object (elf
> file), then unloading and loading them dynamically according to some
> given needs.

What's the use case for loading, then unloading, and then loading again?

> I'm not sure it is possible to load one specific program from the bpf
> object using bpf_object__load() API - is it?

It is possible. You can disable loading BPF program by calling
bpf_program__set_autoload(prog, false) after bpf_object__open() and
before bpf_object__load().

I've thought about adding a convention to SEC() to disable
auto-loading declaratively (e.g., SEC('!kprobe/whatever') won't
auto-load unless autoload is set to true through
bpf_program__set_autoload()), but we haven't implemented that yet.

>
> Another question with the same context -
> If I understand correctly, the purpose of detach is to "prevent
> execution of a previously attached program from any future events"
> (https://facebookmicrosites.github.io/bpf/blog/2018/08/31/object-lifetime.html),
> which seems like something that I would want to do if I just wanted to
> temporarily stop an event from triggering the program. But then I ask
> myself - what is the meaning of detaching a link (and not
> bpf_link__destroy() it) if there is no way to attach it back (without

you mean bpf_link__detach()? this is a special "admin-only" operation
of force-detaching the link, even if there are still link FDs open.
Normally you shouldn't do it. Use bpf_link__destroy() to detach (and
make sure no one dup()'ed extra FDs)

> re-creating the link object)? I don't see any function named
> bpf_link__attach() that would do such a thing, or any other function
> in libbpf API that can do something similar, am I right?

Right, links are created with bpf_program__attach*() APIs.

> Also, It seems that using bpf_link__detach() does not fit all link
> types. For example, when attaching a (non legacy) kprobe, detaching it
> should probably happen using PERF_EVENT_IOC_DISABLE and not through
> sys_bpf(BPF_LINK_DETACH), shouldn't it?
>
> And one last question:
> When using bpf_program__unload() on a program that is already
> attached, should we first call bpf_link__detach() or does the kernel
> already take care of this?

Keep in mind that bpf_program__unload() is also deprecated. The idea
is that if you are working with high-level libbpf APIs that are
centered around struct bpf_object, bpf_program, and bpf_map, the
entire collection of programs and maps is functioning as a single
bundle. If that abstraction doesn't work, you'll have to drop to
low-level APIs (defined in bpf/bpf.h) and manipulate everything
through FDs.

As for detaching (destroying in libbpf lingo, though) the link, yes,
you need to destroy links before unloading the program. Otherwise
links themselves will keep programs loaded in the kernel. Some legacy
links (legacy kprobe/uprobe) won't auto-detach even on process exit
because the kernel doesn't support this.

>
> Thanks,
> Yaniv