Re: Help using libbpf with kernel 4.14

[Yaniv Agman <yanivagman@gmail.com>]

‫בתאריך יום ד׳, 30 בספט׳ 2020 ב-21:34 מאת ‪Andrii Nakryiko‬‏
<‪andrii.nakryiko@gmail.com‬‏>:‬
>
> On Tue, Sep 29, 2020 at 1:25 AM Yaniv Agman <yanivagman@gmail.com> wrote:
> >
> > ‫בתאריך יום ג׳, 29 בספט׳ 2020 ב-4:29 מאת ‪Andrii Nakryiko‬‏
> > <‪andrii.nakryiko@gmail.com‬‏>:‬
> > >
> > > On Mon, Sep 28, 2020 at 5:01 PM Yaniv Agman <yanivagman@gmail.com> wrote:
> > > >
> > > > Hi Andrii,
> > > >
> > > > I used BPF skeleton as you suggested, which did work with kernel 4.19
> > > > but not with 4.14.
> > > > I used the exact same program,  same environment, only changed the
> > > > kernel version.
> > > > The error message I get on 4.14:
> > > >
> > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1
> > > > libbpf: failed to determine kprobe perf type: No such file or directory
> > >
> > > This means that your kernel doesn't support attaching to
> > > kprobe/tracepoint through perf_event subsystem. That's currently the
> > > only way that libbpf supports for kprobe/tracapoint programs. It was
> > > added in 4.17 kernel, which explains what is happening in your case.
> > > It is still possible to attach to kprobe using legacy ways, but libbpf
> > > doesn't provide that out of the box. We had a discussion a while ago
> > > (about 1 year ago) about adding that to libbpf, but at that time we
> > > didn't have a good testing infrastructure to validate such legacy
> > > interfaces, plus it's a bit on the unsafe side as far as APIs go
> > > (there is no auto-detachment and cleanup with how old kernels allow to
> > > do kprobe/tracepoint). But we might reconsider, given it's not a first
> > > time I see people get confused and blocked by this.
> > >
> > > Anyways, here's how you can do it without waiting for libbpf to do
> > > this out of the box:
> > >
> > >
>
> [...]
>
> > >
> > >
> > > Then you'd use it in your application as:
> > >
> > > ...
> > >
> > >   skel->links.handler = attach_kprobe_legacy(
> > >       skel->progs.handler, "do_sys_open", false /* is_kretprobe */);
> > >   if (!skel->links.handler) {
> > >     fprintf(stderr, "Failed to attach kprobe using legacy debugfs API!\n");
> > >     err = 1;
> > >     goto out;
> > >   }
> > >
> > >   ... kprobe is attached here ...
> > >
> > > out:
> > >   /* first clean up step */
> > >   bpf_link__destroy(skel->links.handler);
> > >   /* this is second necessary clean up step */
> > >   remove_kprobe_event("do_sys_open", false /* is_kretprobe */);
> > >
> > >
> > > Let me know if that worked.
> > >
> >
> > Thanks Andrii,
> >
> > I made a small change for the code to compile:
> > skel->links.handler to skel->links.kprobe__do_sys_open and same for skel->progs
> >
> > After compiling the code, I'm now getting the following error:
> > failed to create perf event for kprobe ID 1930: -2
> > Failed to attach kprobe using legacy debugfs API!
> > failed to remove kprobe '-:kprobes/do_sys_open': -2
>
> I've successfully used that code on the kernel as old as 4.9, so this
> must be something about your kernel configuration. E.g., check that
> CONFIG_KPROBE_EVENTS is enabled.

Just wanted to update that this code works!
I didn't include <linux/unistd.h> and for some reason the compiler
didn't complain...
Thank you very much Andrii!

>
> >
> > As our application is written in go,
> > I hoped libbpf would support kernel 3.14 out of the box, so we can
> > just call libbpf functions using cgo wrappers.
> > I can do further checks if you'd like, but I think we will also
> > consider updating the minimal kernel version requirement to 4.18
>
> It's up to you. Of course using a more recent kernel would be much
> better, if you can get away with it.
>
> >
> > > > libbpf: prog 'kprobe__do_sys_open': failed to create kprobe
> > > > 'do_sys_open' perf event: No such file or directory
> > > > libbpf: failed to auto-attach program 'kprobe__do_sys_open': -2
> > > > failed to attach BPF programs: No such file or directory
> > > >
> > >
> > > [...]