* [QUESTION] usage of libbpf_probe_bpf_prog_type API @ 2023-03-30 17:12 andrea terzolo 2023-04-04 22:32 ` Andrii Nakryiko 0 siblings, 1 reply; 7+ messages in thread From: andrea terzolo @ 2023-03-30 17:12 UTC (permalink / raw) To: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API 2023-03-30 17:12 [QUESTION] usage of libbpf_probe_bpf_prog_type API andrea terzolo @ 2023-04-04 22:32 ` Andrii Nakryiko 2023-04-08 13:34 ` andrea terzolo 0 siblings, 1 reply; 7+ messages in thread From: Andrii Nakryiko @ 2023-04-04 22:32 UTC (permalink / raw) To: andrea terzolo; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API 2023-04-04 22:32 ` Andrii Nakryiko @ 2023-04-08 13:34 ` andrea terzolo 2023-04-12 18:48 ` Andrii Nakryiko 0 siblings, 1 reply; 7+ messages in thread From: andrea terzolo @ 2023-04-08 13:34 UTC (permalink / raw) To: Andrii Nakryiko; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API 2023-04-08 13:34 ` andrea terzolo @ 2023-04-12 18:48 ` Andrii Nakryiko 2023-04-13 21:37 ` andrea terzolo 0 siblings, 1 reply; 7+ messages in thread From: Andrii Nakryiko @ 2023-04-12 18:48 UTC (permalink / raw) To: andrea terzolo; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API 2023-04-12 18:48 ` Andrii Nakryiko @ 2023-04-13 21:37 ` andrea terzolo 2023-04-17 23:48 ` Andrii Nakryiko 0 siblings, 1 reply; 7+ messages in thread From: andrea terzolo @ 2023-04-13 21:37 UTC (permalink / raw) To: Andrii Nakryiko; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API 2023-04-13 21:37 ` andrea terzolo @ 2023-04-17 23:48 ` Andrii Nakryiko 2023-04-21 16:34 ` andrea terzolo 0 siblings, 1 reply; 7+ messages in thread From: Andrii Nakryiko @ 2023-04-17 23:48 UTC (permalink / raw) To: andrea terzolo; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [QUESTION] usage of libbpf_probe_bpf_prog_type API 2023-04-17 23:48 ` Andrii Nakryiko @ 2023-04-21 16:34 ` andrea terzolo 0 siblings, 0 replies; 7+ messages in thread From: andrea terzolo @ 2023-04-21 16:34 UTC (permalink / raw) To: Andrii Nakryiko; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-04-21 16:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-30 17:12 [QUESTION] usage of libbpf_probe_bpf_prog_type API andrea terzolo 2023-04-04 22:32 ` Andrii Nakryiko 2023-04-08 13:34 ` andrea terzolo 2023-04-12 18:48 ` Andrii Nakryiko 2023-04-13 21:37 ` andrea terzolo 2023-04-17 23:48 ` Andrii Nakryiko 2023-04-21 16:34 ` andrea terzolo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).