Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il giorno mer 5 apr 2023 alle ore 00:32 Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> ha scritto:
>
> On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
> <andreaterzolo3@xxxxxxxxx> wrote:
> >
> > Hi all!
> >
> > If I can I would like to ask one question about the
> > `libbpf_probe_bpf_prog_type` API. The idea is to use `fentry/fexit`
> > bpf progs only if they are available and fall back to simple `kprobes`
> > when they are not. Is there a way to probe `BPF_TRACE_FENTRY` support
> > with `libbpf` APIs? I was looking at `libbpf_probe_bpf_prog_type` API
> > but it seems to check the `prog_type` rather than the `attach_type`,
> > when I call it `libbpf_probe_bpf_prog_type(BPF_PROG_TYPE_TRACING,
> > NULL);` it returns `1` even if `fentry/fexit` progs are not supported
> > on my machine. Is there a way to probe this feature with other
> > `libbpf` APIs?
> >
>
> looking at libbpf probing code, for BPF_PROG_TYPE_TRACING we choose
> BPF_TRACE_FENTRY attach type automatically (because it doesn't really
> matter whether its BPF_TRACE_FEXIT or BPF_MODIFY_RETURN, they all are
> either supported or none is). We then expect that verifier will
> complain with "attach_btf_id 1 is not a function" error. If we do see
> that error, we know that verifier supports fentry/fexit programs *in
> principle*, which is what we are checking with
> libbpf_probe_bpf_prog_type().

Ok got it, thank you. My issue is that in my project I need to use
BPF_TRACE_RAW_TP programs that AFAIK don't require the support for bpf
trampoline, so they could be supported even if
BPF_TRACE_FENTRY/BPF_MODIFY_RETURN are not supported. This is what
happens on arm64 kernels where we have BPF_TRACE_RAW_TP but
BPF_TRACE_FENTRY/BPF_MODIFY_RETURN are still not supported... Right
now I'm using libbpf_probe_bpf_prog_type() to check the support for
BPF_TRACE_RAW_TP but this is just an approximation, probably the best
way to do that is to inject a small
BPF_TRACE_RAW_TP prog and check that it is correctly loaded. It seems
that libbpf doesn't provide APIs to do that, is it right?

> If kernel doesn't support fentry/fexit attachment for some specific
> function you'd like to attach to, that's a different matter. This
> would be equivalent to BPF_PROG_TYPE_KPROBE check -- we check if
> kprobes in general are supported, but not whether kprobing specific
> kernel function works.
>
> I assume by "not supported on my machine" you mean that you can't
> attach fentry/fexit to some function? If not, let me know, and we'd
> have to debug this further.

Sorry, probably I was not so clear, with this statement I mean that
libbpf_probe_bpf_prog_type() returns 1 even if BPF_TRACE_FENTRY progs
cannot be attached into the kernel. [0] is an example of what I'm
doing.
1. Check fentry support with libbpf_probe_bpf_prog_type
2. Check fentry support with an approach similar to libbpf-tools (as
you suggested)
3. Try to inject my real BPF programs.

(2) (libbpf-tool check) is correctly able to detect that
BPF_TRACE_FENTRY progs are not supported, when we call
`bpf_raw_tracepoint_open` to attach the fentry prog, `524` is returned
so we understand that this program is not supported. On the other
side, (1) is not able to detect that programs are not supported, the
API returns `1` as if they were supported. Now I have to highlight
that this API is called libbpf_probe_bpf_prog_type and not
libbpf_probe_bpf_attach_type, so 1 could be the right return value
since BPF_PROG_TYPE_TRACING progs are effectively supported, for
example, attach_type  BPF_TRACE_RAW_TP is supported, but some other
attach types like BPF_TRACE_FENTRY/BPF_MODIFY_RETURN  are not. If this
API just checks for BPF_PROG_TYPE_TRACING support, probably the best
way I have to check if a specific attach type is supported is to
directly inject a small prog of this type, as libbpf-tool does. WDYT?

[0]: https://github.com/Andreagit97/BPF-perf-tests/blob/main/templates/fentry_attach.c

> If you want to know if some function can be traced with fentry/fexit,
> check below helper function from libbpf-tools ([0])
>
> bool fentry_can_attach(const char *name, const char *mod)
>
>
>   [0] https://github.com/iovisor/bcc/blob/master/libbpf-tools/trace_helpers.c#LL1043-L1043C58
>
Thank you for the pointer!
>
> > Thank you in advance for your time,
> > Andrea




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux