Message ID | 158160616195.80320.5636088335810242866.stgit@xdp-tutorial |
---|---|
State | Changes Requested |
Delegated to: | BPF Maintainers |
Headers | show |
Series | [bpf-next,v2] libbpf: Add support for dynamic program attach target | expand |
Eelco Chaudron <echaudro@redhat.com> writes: > Currently when you want to attach a trace program to a bpf program > the section name needs to match the tracepoint/function semantics. > > However the addition of the bpf_program__set_attach_target() API > allows you to specify the tracepoint/function dynamically. > > The call flow would look something like this: > > xdp_fd = bpf_prog_get_fd_by_id(id); > trace_obj = bpf_object__open_file("func.o", NULL); > prog = bpf_object__find_program_by_title(trace_obj, > "fentry/myfunc"); > bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); > bpf_program__set_attach_target(prog, xdp_fd, > "xdpfilt_blk_all"); > bpf_object__load(trace_obj) > > Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Hmm, one question about the attach_prog_fd usage: > +int bpf_program__set_attach_target(struct bpf_program *prog, > + int attach_prog_fd, > + const char *attach_func_name) > +{ > + int btf_id; > + > + if (!prog || attach_prog_fd < 0 || !attach_func_name) > + return -EINVAL; > + > + if (attach_prog_fd) > + btf_id = libbpf_find_prog_btf_id(attach_func_name, > + attach_prog_fd); > + else > + btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux, > + attach_func_name, > + prog->expected_attach_type); This implies that no one would end up using fd 0 as a legitimate prog fd. This already seems to be the case for the existing code, but is that really a safe assumption? Couldn't a caller that closes fd 0 (for instance while forking) end up having it reused? Seems like this could result in weird hard-to-debug bugs? -Toke
On 13 Feb 2020, at 16:32, Toke Høiland-Jørgensen wrote: > Eelco Chaudron <echaudro@redhat.com> writes: > >> Currently when you want to attach a trace program to a bpf program >> the section name needs to match the tracepoint/function semantics. >> >> However the addition of the bpf_program__set_attach_target() API >> allows you to specify the tracepoint/function dynamically. >> >> The call flow would look something like this: >> >> xdp_fd = bpf_prog_get_fd_by_id(id); >> trace_obj = bpf_object__open_file("func.o", NULL); >> prog = bpf_object__find_program_by_title(trace_obj, >> "fentry/myfunc"); >> bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); >> bpf_program__set_attach_target(prog, xdp_fd, >> "xdpfilt_blk_all"); >> bpf_object__load(trace_obj) >> >> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> > > Hmm, one question about the attach_prog_fd usage: > >> +int bpf_program__set_attach_target(struct bpf_program *prog, >> + int attach_prog_fd, >> + const char *attach_func_name) >> +{ >> + int btf_id; >> + >> + if (!prog || attach_prog_fd < 0 || !attach_func_name) >> + return -EINVAL; >> + >> + if (attach_prog_fd) >> + btf_id = libbpf_find_prog_btf_id(attach_func_name, >> + attach_prog_fd); >> + else >> + btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux, >> + attach_func_name, >> + prog->expected_attach_type); > > This implies that no one would end up using fd 0 as a legitimate prog > fd. This already seems to be the case for the existing code, but is > that > really a safe assumption? Couldn't a caller that closes fd 0 (for > instance while forking) end up having it reused? Seems like this could > result in weird hard-to-debug bugs? Yes, in theory, this can happen but it has nothing to do with this specific patch. The existing code already assumes that attach_prog_fd == 0 means attach to a kernel function :(
"Eelco Chaudron" <echaudro@redhat.com> writes: > On 13 Feb 2020, at 16:32, Toke Høiland-Jørgensen wrote: > >> Eelco Chaudron <echaudro@redhat.com> writes: >> >>> Currently when you want to attach a trace program to a bpf program >>> the section name needs to match the tracepoint/function semantics. >>> >>> However the addition of the bpf_program__set_attach_target() API >>> allows you to specify the tracepoint/function dynamically. >>> >>> The call flow would look something like this: >>> >>> xdp_fd = bpf_prog_get_fd_by_id(id); >>> trace_obj = bpf_object__open_file("func.o", NULL); >>> prog = bpf_object__find_program_by_title(trace_obj, >>> "fentry/myfunc"); >>> bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); >>> bpf_program__set_attach_target(prog, xdp_fd, >>> "xdpfilt_blk_all"); >>> bpf_object__load(trace_obj) >>> >>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> >> >> Hmm, one question about the attach_prog_fd usage: >> >>> +int bpf_program__set_attach_target(struct bpf_program *prog, >>> + int attach_prog_fd, >>> + const char *attach_func_name) >>> +{ >>> + int btf_id; >>> + >>> + if (!prog || attach_prog_fd < 0 || !attach_func_name) >>> + return -EINVAL; >>> + >>> + if (attach_prog_fd) >>> + btf_id = libbpf_find_prog_btf_id(attach_func_name, >>> + attach_prog_fd); >>> + else >>> + btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux, >>> + attach_func_name, >>> + prog->expected_attach_type); >> >> This implies that no one would end up using fd 0 as a legitimate prog >> fd. This already seems to be the case for the existing code, but is >> that >> really a safe assumption? Couldn't a caller that closes fd 0 (for >> instance while forking) end up having it reused? Seems like this could >> result in weird hard-to-debug bugs? > > > Yes, in theory, this can happen but it has nothing to do with this > specific patch. The existing code already assumes that attach_prog_fd == > 0 means attach to a kernel function :( Yup, I do realise you're just sticking to the existing behaviour. Seems even the kernel does that check for fd != 0, so I guess that's ABI now. Still not sure I believe this will not trip anyone up, though... :/ -Toke
Eelco Chaudron <echaudro@redhat.com> writes: > Currently when you want to attach a trace program to a bpf program > the section name needs to match the tracepoint/function semantics. > > However the addition of the bpf_program__set_attach_target() API > allows you to specify the tracepoint/function dynamically. > > The call flow would look something like this: > > xdp_fd = bpf_prog_get_fd_by_id(id); > trace_obj = bpf_object__open_file("func.o", NULL); > prog = bpf_object__find_program_by_title(trace_obj, > "fentry/myfunc"); > bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); > bpf_program__set_attach_target(prog, xdp_fd, > "xdpfilt_blk_all"); > bpf_object__load(trace_obj) > > Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
On Thu, Feb 13, 2020 at 7:05 AM Eelco Chaudron <echaudro@redhat.com> wrote: > > Currently when you want to attach a trace program to a bpf program > the section name needs to match the tracepoint/function semantics. > > However the addition of the bpf_program__set_attach_target() API > allows you to specify the tracepoint/function dynamically. > > The call flow would look something like this: > > xdp_fd = bpf_prog_get_fd_by_id(id); > trace_obj = bpf_object__open_file("func.o", NULL); > prog = bpf_object__find_program_by_title(trace_obj, > "fentry/myfunc"); > bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); > bpf_program__set_attach_target(prog, xdp_fd, > "xdpfilt_blk_all"); > bpf_object__load(trace_obj) > > Signed-off-by: Eelco Chaudron <echaudro@redhat.com> > --- API-wise this looks good, thanks! Please address feedback below and re-submit once bpf-next opens. Can you please also convert one of existing selftests using open_opts's attach_prog_fd to use this API instead to have a demonstration there? > v1 -> v2: Remove requirement for attach type name in API > > tools/lib/bpf/libbpf.c | 33 +++++++++++++++++++++++++++++++-- > tools/lib/bpf/libbpf.h | 4 ++++ > tools/lib/bpf/libbpf.map | 1 + > 3 files changed, 36 insertions(+), 2 deletions(-) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 514b1a524abb..9b8cab995580 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -4939,8 +4939,8 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) > { > int err = 0, fd, i, btf_id; > > - if (prog->type == BPF_PROG_TYPE_TRACING || > - prog->type == BPF_PROG_TYPE_EXT) { > + if ((prog->type == BPF_PROG_TYPE_TRACING || > + prog->type == BPF_PROG_TYPE_EXT) && !prog->attach_btf_id) { > btf_id = libbpf_find_attach_btf_id(prog); > if (btf_id <= 0) > return btf_id; > @@ -8132,6 +8132,35 @@ void bpf_program__bpil_offs_to_addr(struct bpf_prog_info_linear *info_linear) > } > } > > +int bpf_program__set_attach_target(struct bpf_program *prog, > + int attach_prog_fd, > + const char *attach_func_name) > +{ > + int btf_id; > + > + if (!prog || attach_prog_fd < 0 || !attach_func_name) > + return -EINVAL; > + > + if (attach_prog_fd) > + btf_id = libbpf_find_prog_btf_id(attach_func_name, > + attach_prog_fd); > + else > + btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux, > + attach_func_name, > + prog->expected_attach_type); > + > + if (btf_id <= 0) { > + if (!attach_prog_fd) > + pr_warn("%s is not found in vmlinux BTF\n", > + attach_func_name); libbpf_find_attach_btf_id's error reporting is misleading (it always reports as if error happened with vmlinux BTF, even if attach_prog_fd > 0). Could you please fix that and add better error reporting here for attach_prog_fd>0 case here? > + return btf_id; > + } > + > + prog->attach_btf_id = btf_id; > + prog->attach_prog_fd = attach_prog_fd; > + return 0; > +} > + > int parse_cpu_mask_str(const char *s, bool **mask, int *mask_sz) > { > int err = 0, n, len, start, end = -1; > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > index 3fe12c9d1f92..02fc58a21a7f 100644 > --- a/tools/lib/bpf/libbpf.h > +++ b/tools/lib/bpf/libbpf.h > @@ -334,6 +334,10 @@ LIBBPF_API void > bpf_program__set_expected_attach_type(struct bpf_program *prog, > enum bpf_attach_type type); > > +LIBBPF_API int > +bpf_program__set_attach_target(struct bpf_program *prog, int attach_prog_fd, > + const char *attach_func_name); > + > LIBBPF_API bool bpf_program__is_socket_filter(const struct bpf_program *prog); > LIBBPF_API bool bpf_program__is_tracepoint(const struct bpf_program *prog); > LIBBPF_API bool bpf_program__is_raw_tracepoint(const struct bpf_program *prog); > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map > index b035122142bb..8aba5438a3f0 100644 > --- a/tools/lib/bpf/libbpf.map > +++ b/tools/lib/bpf/libbpf.map > @@ -230,6 +230,7 @@ LIBBPF_0.0.7 { > bpf_program__name; > bpf_program__is_extension; > bpf_program__is_struct_ops; > + bpf_program__set_attach_target; This will have to go into LIBBPF_0.0.8 once bpf-next opens. Please rebase and re-send then. > bpf_program__set_extension; > bpf_program__set_struct_ops; > btf__align_of; >
On 13 Feb 2020, at 18:42, Andrii Nakryiko wrote: > On Thu, Feb 13, 2020 at 7:05 AM Eelco Chaudron <echaudro@redhat.com> > wrote: >> >> Currently when you want to attach a trace program to a bpf program >> the section name needs to match the tracepoint/function semantics. >> >> However the addition of the bpf_program__set_attach_target() API >> allows you to specify the tracepoint/function dynamically. >> >> The call flow would look something like this: >> >> xdp_fd = bpf_prog_get_fd_by_id(id); >> trace_obj = bpf_object__open_file("func.o", NULL); >> prog = bpf_object__find_program_by_title(trace_obj, >> "fentry/myfunc"); >> bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); >> bpf_program__set_attach_target(prog, xdp_fd, >> "xdpfilt_blk_all"); >> bpf_object__load(trace_obj) >> >> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> >> --- > > API-wise this looks good, thanks! Please address feedback below and > re-submit once bpf-next opens. Can you please also convert one of > existing selftests using open_opts's attach_prog_fd to use this API > instead to have a demonstration there? Yes will update the one I added for bfp2bpf testing… >> v1 -> v2: Remove requirement for attach type name in API >> >> tools/lib/bpf/libbpf.c | 33 +++++++++++++++++++++++++++++++-- >> tools/lib/bpf/libbpf.h | 4 ++++ >> tools/lib/bpf/libbpf.map | 1 + >> 3 files changed, 36 insertions(+), 2 deletions(-) >> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >> index 514b1a524abb..9b8cab995580 100644 >> --- a/tools/lib/bpf/libbpf.c >> +++ b/tools/lib/bpf/libbpf.c >> @@ -4939,8 +4939,8 @@ int bpf_program__load(struct bpf_program *prog, >> char *license, __u32 kern_ver) >> { >> int err = 0, fd, i, btf_id; >> >> - if (prog->type == BPF_PROG_TYPE_TRACING || >> - prog->type == BPF_PROG_TYPE_EXT) { >> + if ((prog->type == BPF_PROG_TYPE_TRACING || >> + prog->type == BPF_PROG_TYPE_EXT) && >> !prog->attach_btf_id) { >> btf_id = libbpf_find_attach_btf_id(prog); >> if (btf_id <= 0) >> return btf_id; >> @@ -8132,6 +8132,35 @@ void bpf_program__bpil_offs_to_addr(struct >> bpf_prog_info_linear *info_linear) >> } >> } >> >> +int bpf_program__set_attach_target(struct bpf_program *prog, >> + int attach_prog_fd, >> + const char *attach_func_name) >> +{ >> + int btf_id; >> + >> + if (!prog || attach_prog_fd < 0 || !attach_func_name) >> + return -EINVAL; >> + >> + if (attach_prog_fd) >> + btf_id = libbpf_find_prog_btf_id(attach_func_name, >> + attach_prog_fd); >> + else >> + btf_id = >> __find_vmlinux_btf_id(prog->obj->btf_vmlinux, >> + attach_func_name, >> + >> prog->expected_attach_type); >> + >> + if (btf_id <= 0) { >> + if (!attach_prog_fd) >> + pr_warn("%s is not found in vmlinux BTF\n", >> + attach_func_name); > > libbpf_find_attach_btf_id's error reporting is misleading (it always > reports as if error happened with vmlinux BTF, even if attach_prog_fd > 0). Could you please fix that and add better error reporting here > for attach_prog_fd>0 case here? > I did not add log messages for the btf_id > 0 case as they are covered in the libbpf_find_prog_btf_id() function. Please let me know if this is not enough. >> + return btf_id; >> + } >> + >> + prog->attach_btf_id = btf_id; >> + prog->attach_prog_fd = attach_prog_fd; >> + return 0; >> +} >> + >> int parse_cpu_mask_str(const char *s, bool **mask, int *mask_sz) >> { >> int err = 0, n, len, start, end = -1; >> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h >> index 3fe12c9d1f92..02fc58a21a7f 100644 >> --- a/tools/lib/bpf/libbpf.h >> +++ b/tools/lib/bpf/libbpf.h >> @@ -334,6 +334,10 @@ LIBBPF_API void >> bpf_program__set_expected_attach_type(struct bpf_program *prog, >> enum bpf_attach_type type); >> >> +LIBBPF_API int >> +bpf_program__set_attach_target(struct bpf_program *prog, int >> attach_prog_fd, >> + const char *attach_func_name); >> + >> LIBBPF_API bool bpf_program__is_socket_filter(const struct >> bpf_program *prog); >> LIBBPF_API bool bpf_program__is_tracepoint(const struct bpf_program >> *prog); >> LIBBPF_API bool bpf_program__is_raw_tracepoint(const struct >> bpf_program *prog); >> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map >> index b035122142bb..8aba5438a3f0 100644 >> --- a/tools/lib/bpf/libbpf.map >> +++ b/tools/lib/bpf/libbpf.map >> @@ -230,6 +230,7 @@ LIBBPF_0.0.7 { >> bpf_program__name; >> bpf_program__is_extension; >> bpf_program__is_struct_ops; >> + bpf_program__set_attach_target; > > This will have to go into LIBBPF_0.0.8 once bpf-next opens. Please > rebase and re-send then. Will do… >> bpf_program__set_extension; >> bpf_program__set_struct_ops; >> btf__align_of; >>
On Thu, Feb 13, 2020 at 11:34 PM Eelco Chaudron <echaudro@redhat.com> wrote: > > > > On 13 Feb 2020, at 18:42, Andrii Nakryiko wrote: > > > On Thu, Feb 13, 2020 at 7:05 AM Eelco Chaudron <echaudro@redhat.com> > > wrote: > >> > >> Currently when you want to attach a trace program to a bpf program > >> the section name needs to match the tracepoint/function semantics. > >> > >> However the addition of the bpf_program__set_attach_target() API > >> allows you to specify the tracepoint/function dynamically. > >> > >> The call flow would look something like this: > >> > >> xdp_fd = bpf_prog_get_fd_by_id(id); > >> trace_obj = bpf_object__open_file("func.o", NULL); > >> prog = bpf_object__find_program_by_title(trace_obj, > >> "fentry/myfunc"); > >> bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); > >> bpf_program__set_attach_target(prog, xdp_fd, > >> "xdpfilt_blk_all"); > >> bpf_object__load(trace_obj) > >> > >> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> > >> --- > > > > API-wise this looks good, thanks! Please address feedback below and > > re-submit once bpf-next opens. Can you please also convert one of > > existing selftests using open_opts's attach_prog_fd to use this API > > instead to have a demonstration there? > > Yes will update the one I added for bfp2bpf testing… > > >> v1 -> v2: Remove requirement for attach type name in API > >> > >> tools/lib/bpf/libbpf.c | 33 +++++++++++++++++++++++++++++++-- > >> tools/lib/bpf/libbpf.h | 4 ++++ > >> tools/lib/bpf/libbpf.map | 1 + > >> 3 files changed, 36 insertions(+), 2 deletions(-) > >> > >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > >> index 514b1a524abb..9b8cab995580 100644 > >> --- a/tools/lib/bpf/libbpf.c > >> +++ b/tools/lib/bpf/libbpf.c > >> @@ -4939,8 +4939,8 @@ int bpf_program__load(struct bpf_program *prog, > >> char *license, __u32 kern_ver) > >> { > >> int err = 0, fd, i, btf_id; > >> > >> - if (prog->type == BPF_PROG_TYPE_TRACING || > >> - prog->type == BPF_PROG_TYPE_EXT) { > >> + if ((prog->type == BPF_PROG_TYPE_TRACING || > >> + prog->type == BPF_PROG_TYPE_EXT) && > >> !prog->attach_btf_id) { > >> btf_id = libbpf_find_attach_btf_id(prog); > >> if (btf_id <= 0) > >> return btf_id; > >> @@ -8132,6 +8132,35 @@ void bpf_program__bpil_offs_to_addr(struct > >> bpf_prog_info_linear *info_linear) > >> } > >> } > >> > >> +int bpf_program__set_attach_target(struct bpf_program *prog, > >> + int attach_prog_fd, > >> + const char *attach_func_name) > >> +{ > >> + int btf_id; > >> + > >> + if (!prog || attach_prog_fd < 0 || !attach_func_name) > >> + return -EINVAL; > >> + > >> + if (attach_prog_fd) > >> + btf_id = libbpf_find_prog_btf_id(attach_func_name, > >> + attach_prog_fd); > >> + else > >> + btf_id = > >> __find_vmlinux_btf_id(prog->obj->btf_vmlinux, > >> + attach_func_name, > >> + > >> prog->expected_attach_type); > >> + > >> + if (btf_id <= 0) { > >> + if (!attach_prog_fd) > >> + pr_warn("%s is not found in vmlinux BTF\n", > >> + attach_func_name); > > > > libbpf_find_attach_btf_id's error reporting is misleading (it always > > reports as if error happened with vmlinux BTF, even if attach_prog_fd > > 0). Could you please fix that and add better error reporting here > > for attach_prog_fd>0 case here? > > > > I did not add log messages for the btf_id > 0 case as they are covered > in the libbpf_find_prog_btf_id() function. Please let me know if this is > not enough. I see... libbpf_find_attach_btf_id is still wrong, so maybe let's move this warning into __find_vmlinux_btf_id for more symmetrical (with libbpf_find_prog_btf_id) error reporting? > > >> + return btf_id; > >> + } > >> + > >> + prog->attach_btf_id = btf_id; > >> + prog->attach_prog_fd = attach_prog_fd; > >> + return 0; > >> +} > >> + > >> int parse_cpu_mask_str(const char *s, bool **mask, int *mask_sz) > >> { > >> int err = 0, n, len, start, end = -1; > >> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > >> index 3fe12c9d1f92..02fc58a21a7f 100644 > >> --- a/tools/lib/bpf/libbpf.h > >> +++ b/tools/lib/bpf/libbpf.h > >> @@ -334,6 +334,10 @@ LIBBPF_API void > >> bpf_program__set_expected_attach_type(struct bpf_program *prog, > >> enum bpf_attach_type type); > >> > >> +LIBBPF_API int > >> +bpf_program__set_attach_target(struct bpf_program *prog, int > >> attach_prog_fd, > >> + const char *attach_func_name); > >> + > >> LIBBPF_API bool bpf_program__is_socket_filter(const struct > >> bpf_program *prog); > >> LIBBPF_API bool bpf_program__is_tracepoint(const struct bpf_program > >> *prog); > >> LIBBPF_API bool bpf_program__is_raw_tracepoint(const struct > >> bpf_program *prog); > >> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map > >> index b035122142bb..8aba5438a3f0 100644 > >> --- a/tools/lib/bpf/libbpf.map > >> +++ b/tools/lib/bpf/libbpf.map > >> @@ -230,6 +230,7 @@ LIBBPF_0.0.7 { > >> bpf_program__name; > >> bpf_program__is_extension; > >> bpf_program__is_struct_ops; > >> + bpf_program__set_attach_target; > > > > This will have to go into LIBBPF_0.0.8 once bpf-next opens. Please > > rebase and re-send then. > > Will do… > > >> bpf_program__set_extension; > >> bpf_program__set_struct_ops; > >> btf__align_of; > >> >
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 514b1a524abb..9b8cab995580 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -4939,8 +4939,8 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) { int err = 0, fd, i, btf_id; - if (prog->type == BPF_PROG_TYPE_TRACING || - prog->type == BPF_PROG_TYPE_EXT) { + if ((prog->type == BPF_PROG_TYPE_TRACING || + prog->type == BPF_PROG_TYPE_EXT) && !prog->attach_btf_id) { btf_id = libbpf_find_attach_btf_id(prog); if (btf_id <= 0) return btf_id; @@ -8132,6 +8132,35 @@ void bpf_program__bpil_offs_to_addr(struct bpf_prog_info_linear *info_linear) } } +int bpf_program__set_attach_target(struct bpf_program *prog, + int attach_prog_fd, + const char *attach_func_name) +{ + int btf_id; + + if (!prog || attach_prog_fd < 0 || !attach_func_name) + return -EINVAL; + + if (attach_prog_fd) + btf_id = libbpf_find_prog_btf_id(attach_func_name, + attach_prog_fd); + else + btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux, + attach_func_name, + prog->expected_attach_type); + + if (btf_id <= 0) { + if (!attach_prog_fd) + pr_warn("%s is not found in vmlinux BTF\n", + attach_func_name); + return btf_id; + } + + prog->attach_btf_id = btf_id; + prog->attach_prog_fd = attach_prog_fd; + return 0; +} + int parse_cpu_mask_str(const char *s, bool **mask, int *mask_sz) { int err = 0, n, len, start, end = -1; diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h index 3fe12c9d1f92..02fc58a21a7f 100644 --- a/tools/lib/bpf/libbpf.h +++ b/tools/lib/bpf/libbpf.h @@ -334,6 +334,10 @@ LIBBPF_API void bpf_program__set_expected_attach_type(struct bpf_program *prog, enum bpf_attach_type type); +LIBBPF_API int +bpf_program__set_attach_target(struct bpf_program *prog, int attach_prog_fd, + const char *attach_func_name); + LIBBPF_API bool bpf_program__is_socket_filter(const struct bpf_program *prog); LIBBPF_API bool bpf_program__is_tracepoint(const struct bpf_program *prog); LIBBPF_API bool bpf_program__is_raw_tracepoint(const struct bpf_program *prog); diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map index b035122142bb..8aba5438a3f0 100644 --- a/tools/lib/bpf/libbpf.map +++ b/tools/lib/bpf/libbpf.map @@ -230,6 +230,7 @@ LIBBPF_0.0.7 { bpf_program__name; bpf_program__is_extension; bpf_program__is_struct_ops; + bpf_program__set_attach_target; bpf_program__set_extension; bpf_program__set_struct_ops; btf__align_of;
Currently when you want to attach a trace program to a bpf program the section name needs to match the tracepoint/function semantics. However the addition of the bpf_program__set_attach_target() API allows you to specify the tracepoint/function dynamically. The call flow would look something like this: xdp_fd = bpf_prog_get_fd_by_id(id); trace_obj = bpf_object__open_file("func.o", NULL); prog = bpf_object__find_program_by_title(trace_obj, "fentry/myfunc"); bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); bpf_program__set_attach_target(prog, xdp_fd, "xdpfilt_blk_all"); bpf_object__load(trace_obj) Signed-off-by: Eelco Chaudron <echaudro@redhat.com> --- v1 -> v2: Remove requirement for attach type name in API tools/lib/bpf/libbpf.c | 33 +++++++++++++++++++++++++++++++-- tools/lib/bpf/libbpf.h | 4 ++++ tools/lib/bpf/libbpf.map | 1 + 3 files changed, 36 insertions(+), 2 deletions(-)