On Sun, Oct 4, 2020 at 3:52 PM Yaniv Agman <yanivagman@xxxxxxxxx> wrote:
>
> בתאריך יום ד׳, 30 בספט׳ 2020 ב-21:34 מאת Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx>:
> >
> > On Tue, Sep 29, 2020 at 1:25 AM Yaniv Agman <yanivagman@xxxxxxxxx> wrote:
> > >
> > > בתאריך יום ג׳, 29 בספט׳ 2020 ב-4:29 מאת Andrii Nakryiko
> > > <andrii.nakryiko@xxxxxxxxx>:
> > > >
> > > > On Mon, Sep 28, 2020 at 5:01 PM Yaniv Agman <yanivagman@xxxxxxxxx> 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!
You are welcome, I'm glad you figured it out.
>
> >
> > >
> > > 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
> > > > >
> > > >
> > > > [...]
