bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yaniv Agman <yanivagman@gmail.com>
To: bpf <bpf@vger.kernel.org>, Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: michael.tcherniack@aquasec.com
Subject: libbpf API: dynamically load(/unload/attach/detach) bpf programs question
Date: Tue, 11 Jan 2022 14:33:11 +0200	[thread overview]
Message-ID: <CAMy7=ZXqyoaw0mOk2Z8ADxUSs95B=SRgvTua3vRJ00nS5qTFgQ@mail.gmail.com> (raw)

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.
I'm not sure it is possible to load one specific program from the bpf
object using bpf_object__load() API - is it?

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

Thanks,
Yaniv

             reply	other threads:[~2022-01-11 12:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 12:33 Yaniv Agman [this message]
2022-01-11 20:58 ` libbpf API: dynamically load(/unload/attach/detach) bpf programs question Andrii Nakryiko
2022-01-12 10:42   ` Yaniv Agman
2022-01-14 20:03     ` Andrii Nakryiko
2022-01-17  6:57       ` Yaniv Agman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMy7=ZXqyoaw0mOk2Z8ADxUSs95B=SRgvTua3vRJ00nS5qTFgQ@mail.gmail.com' \
    --to=yanivagman@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=michael.tcherniack@aquasec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).