On 9/14/23 11:05, Andrii Nakryiko wrote:
On Tue, Sep 12, 2023 at 11:50 AM Martin Kelly
<martin.kelly@xxxxxxxxxxxxxxx> wrote:
Hi all,
I'm trying to figure out the best way to handle the fact that
fentry/fexit trampolines are not fully supported on all architectures
and kernel versions. As an example, I want to be able to load an fentry
if the kernel supports it, and a kprobe otherwise.
It's tempting to use libbpf_probe_bpf_prog_type for this, but on ARM64
kernels >= 5.5 (when BPF trampolines were introduced) but before the
most recent ones, loading an fentry program will pass, but attaching it
will still fail. This also means that libbpf_probe_bpf_prog_type will
return true even if the program can't be attached, so that can't be used
to test for attachability.
Right, because libbpf_probe_bpf_prog_type() is testing whether given
program type can be loaded, not attached.
I can work around this by attempting to attach a dummy fentry program in
my application, but I'm wondering if this is something that should be
done more generally by libbpf. Some possible ways to do this are:
- Extend the libbpf_probe API to add libbpf_probe_trampoline or similar,
attempting attach to a known-exported function, such as the BPF syscall,
or to a user-specified symbol.
- Extend the libbpf_probe API to add a generic libbpf_probe_attach API
to check if a given function is attachable. However, as attach code is
different depending on the hook, this might be very complex and require
a ton of parameters.
- Maybe there are other options that I haven't thought of.
I have a patch I could send for libbpf_probe_trampoline, but I wanted to
first check if this is a good idea or if it's preferred to simply have
applications probe this themselves.
It doesn't seem too hard for an application to try to attach and if
attachment fails fallback to attaching kprobe-based program. So I'd
prefer that over much more maintenance burden of keeping this "can
attach" generic API. At least for now.
OK, it's easy enough to do it in the application, so we'll do that. Thanks!
Thanks,
Martin
