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. > > Thanks, > > Martin > >
