[QUESTION] usage of libbpf_probe_bpf_prog_type API

[QUESTION] usage of libbpf_probe_bpf_prog_type API

[andrea terzolo]

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?

Thank you in advance for your time,
Andrea

Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[Andrii Nakryiko]

On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
<andreaterzolo3@gmail.com> 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().

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.

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 in advance for your time,
> Andrea

Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[andrea terzolo]

Il giorno mer 5 apr 2023 alle ore 00:32 Andrii Nakryiko
<andrii.nakryiko@gmail.com> ha scritto:
>
> On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
> <andreaterzolo3@gmail.com> 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

Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[Andrii Nakryiko]

On Sat, Apr 8, 2023 at 6:34 AM andrea terzolo <andreaterzolo3@gmail.com> wrote:
>
> Il giorno mer 5 apr 2023 alle ore 00:32 Andrii Nakryiko
> <andrii.nakryiko@gmail.com> ha scritto:
> >
> > On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
> > <andreaterzolo3@gmail.com> 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?

BPF_TRACE_RAW_TP is not a program type, so not sure what you are checking.

fentry/fexit is BPF_PROG_TYPE_TRACING, while raw tracepoint is
BPF_PROG_TYPE_RAW_TRACEPOINT, there shouldn't be any problem for you.

>
> > 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?

Could it be that you are mixing up enum bpf_prog_type with enum
bpf_attach_type when calling libbpf_probe_bpf_prog_type()?

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

Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[andrea terzolo]

On Wed, 12 Apr 2023 at 20:48, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Sat, Apr 8, 2023 at 6:34 AM andrea terzolo <andreaterzolo3@gmail.com> wrote:
> >
> > Il giorno mer 5 apr 2023 alle ore 00:32 Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> ha scritto:
> > >
> > > On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
> > > <andreaterzolo3@gmail.com> 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?
>
> BPF_TRACE_RAW_TP is not a program type, so not sure what you are checking.
>
> fentry/fexit is BPF_PROG_TYPE_TRACING, while raw tracepoint is
> BPF_PROG_TYPE_RAW_TRACEPOINT, there shouldn't be any problem for you.

If I understood correctly BPF_PROG_TYPE_TRACING has several attach types:
* BPF_MODIFY_RETURN
* BPF_TRACE_FENTRY
* BPF_TRACE_FEXIT
* BPF_TRACE_ITER
* BPF_TRACE_RAW_TP

I'm using the last one so BPF_TRACE_RAW_TP ('tp_btf' elf section
name). libbpf_probe_bpf_prog_type API allows checking the support for
a specific prog_type like BPF_PROG_TYPE_TRACING but indeed I need a
check on the attach_type support. BPF_TRACE_FENTRY/FEXIT have
different requirements with respect to BPF_TRACE_RAW_TP so I would
like to know if libbpf provides out-of-the-box an API to check the
attach_type support. libbpf_probe_bpf_prog_type doesn't tell if
BPF_TRACE_FENTRY/FEXIT are effectively supported it just tells if
BPF_PROG_TYPE_TRACING is supported, so I was just asking what is the
best way to probe the support for a specific attach_type

>
> >
> > > 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?
>
> Could it be that you are mixing up enum bpf_prog_type with enum
> bpf_attach_type when calling libbpf_probe_bpf_prog_type()?
>
> >
> > [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

Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[Andrii Nakryiko]

On Thu, Apr 13, 2023 at 2:37 PM andrea terzolo <andreaterzolo3@gmail.com> wrote:
>
> On Wed, 12 Apr 2023 at 20:48, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Sat, Apr 8, 2023 at 6:34 AM andrea terzolo <andreaterzolo3@gmail.com> wrote:
> > >
> > > Il giorno mer 5 apr 2023 alle ore 00:32 Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> ha scritto:
> > > >
> > > > On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
> > > > <andreaterzolo3@gmail.com> 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?
> >
> > BPF_TRACE_RAW_TP is not a program type, so not sure what you are checking.
> >
> > fentry/fexit is BPF_PROG_TYPE_TRACING, while raw tracepoint is
> > BPF_PROG_TYPE_RAW_TRACEPOINT, there shouldn't be any problem for you.
>
> If I understood correctly BPF_PROG_TYPE_TRACING has several attach types:
> * BPF_MODIFY_RETURN
> * BPF_TRACE_FENTRY
> * BPF_TRACE_FEXIT
> * BPF_TRACE_ITER
> * BPF_TRACE_RAW_TP
>
> I'm using the last one so BPF_TRACE_RAW_TP ('tp_btf' elf section

ah, so we were talking about BTF-aware raw tracepoint, sorry, I missed
that. Was thinking about plain raw tracepoint all along the way.

> name). libbpf_probe_bpf_prog_type API allows checking the support for
> a specific prog_type like BPF_PROG_TYPE_TRACING but indeed I need a
> check on the attach_type support. BPF_TRACE_FENTRY/FEXIT have
> different requirements with respect to BPF_TRACE_RAW_TP so I would
> like to know if libbpf provides out-of-the-box an API to check the
> attach_type support. libbpf_probe_bpf_prog_type doesn't tell if
> BPF_TRACE_FENTRY/FEXIT are effectively supported it just tells if
> BPF_PROG_TYPE_TRACING is supported, so I was just asking what is the
> best way to probe the support for a specific attach_type

ok, this sounds like a perfect use case to use that opts argument and
allow programs to optionally specify expected_attach_type. see
LIBBPF_OPTS, OPTS_GET and other cases of using `struct xxx_opts` in
libbpf code base.

Would you be interested in contributing such a patch?

>
> >
> > >
> > > > 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?
> >
> > Could it be that you are mixing up enum bpf_prog_type with enum
> > bpf_attach_type when calling libbpf_probe_bpf_prog_type()?
> >
> > >
> > > [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

Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API

[andrea terzolo]

On Tue, 18 Apr 2023 at 01:48, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Apr 13, 2023 at 2:37 PM andrea terzolo <andreaterzolo3@gmail.com> wrote:
> >
> > On Wed, 12 Apr 2023 at 20:48, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Sat, Apr 8, 2023 at 6:34 AM andrea terzolo <andreaterzolo3@gmail.com> wrote:
> > > >
> > > > Il giorno mer 5 apr 2023 alle ore 00:32 Andrii Nakryiko
> > > > <andrii.nakryiko@gmail.com> ha scritto:
> > > > >
> > > > > On Thu, Mar 30, 2023 at 10:21 AM andrea terzolo
> > > > > <andreaterzolo3@gmail.com> 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?
> > >
> > > BPF_TRACE_RAW_TP is not a program type, so not sure what you are checking.
> > >
> > > fentry/fexit is BPF_PROG_TYPE_TRACING, while raw tracepoint is
> > > BPF_PROG_TYPE_RAW_TRACEPOINT, there shouldn't be any problem for you.
> >
> > If I understood correctly BPF_PROG_TYPE_TRACING has several attach types:
> > * BPF_MODIFY_RETURN
> > * BPF_TRACE_FENTRY
> > * BPF_TRACE_FEXIT
> > * BPF_TRACE_ITER
> > * BPF_TRACE_RAW_TP
> >
> > I'm using the last one so BPF_TRACE_RAW_TP ('tp_btf' elf section
>
> ah, so we were talking about BTF-aware raw tracepoint, sorry, I missed
> that. Was thinking about plain raw tracepoint all along the way.
>
> > name). libbpf_probe_bpf_prog_type API allows checking the support for
> > a specific prog_type like BPF_PROG_TYPE_TRACING but indeed I need a
> > check on the attach_type support. BPF_TRACE_FENTRY/FEXIT have
> > different requirements with respect to BPF_TRACE_RAW_TP so I would
> > like to know if libbpf provides out-of-the-box an API to check the
> > attach_type support. libbpf_probe_bpf_prog_type doesn't tell if
> > BPF_TRACE_FENTRY/FEXIT are effectively supported it just tells if
> > BPF_PROG_TYPE_TRACING is supported, so I was just asking what is the
> > best way to probe the support for a specific attach_type
>
> ok, this sounds like a perfect use case to use that opts argument and
> allow programs to optionally specify expected_attach_type. see
> LIBBPF_OPTS, OPTS_GET and other cases of using `struct xxx_opts` in
> libbpf code base.
>
> Would you be interested in contributing such a patch?

Right now I'm pretty busy but if there is no rush I can try to
implement it when I have time! BTW thank you for the suggestion, I
will take a look at `LIBBPF_OPTS, OPTS_GET` constructs!
> >
> > >
> > > >
> > > > > 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?
> > >
> > > Could it be that you are mixing up enum bpf_prog_type with enum
> > > bpf_attach_type when calling libbpf_probe_bpf_prog_type()?
> > >
> > > >
> > > > [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