On 13 Feb 2020, at 16:32, Toke Høiland-Jørgensen wrote:
Eelco Chaudron <echaudro@xxxxxxxxxx> 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@xxxxxxxxxx>
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 :(
