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.
>
> 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
> > >
> >
> > [...]
