Alan Maguire <alan.maguire@xxxxxxxxxx> writes: > On Tue, 12 May 2020, Toke Høiland-Jørgensen wrote: > >> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: >> >> >> > Currently fentry/fexit/freplace progs have single prog->aux->linked_prog pointer. >> >> > It just needs to become a linked list. >> >> > The api extension could be like this: >> >> > bpf_raw_tp_open(prog_fd, attach_prog_fd, attach_btf_id); >> >> > (currently it's just bpf_raw_tp_open(prog_fd)) >> >> > The same pair of (attach_prog_fd, attach_btf_id) is already passed into prog_load >> >> > to hold the linked_prog and its corresponding btf_id. >> >> > I'm proposing to extend raw_tp_open with this pair as well to >> >> > attach existing fentry/fexit/freplace prog to another target. >> >> > Internally the kernel verify that btf of current linked_prog >> >> > exactly matches to btf of another requested linked_prog and >> >> > if they match it will attach the same prog to two target programs (in case of freplace) >> >> > or two kernel functions (in case of fentry/fexit). >> >> >> >> API-wise this was exactly what I had in mind as well. >> > >> > perfect! >> > > Apologies in advance if I've missed a way to do this, but > for fentry/fexit, if we could attach the same program to > multiple kernel functions, it would be great it we could > programmatically access the BTF func proto id for the > attached function (prog->aux->attach_btf_id I think?). Yes! I pushed for adding this to the GET_LINK_INFO operation, but it wasn't included the first time around; I still think it ought to be added. Actually in general, getting the btf_id of the currently running function for any type of BPF program would be good; e.g., for xdpdump we want to attach to a running XDP program, but we need the btf_id of the main function. And because the name can be truncated to BPF_OBJ_NAME_LEN when returned from the kernel, we have to walk the BTF info for the program, and basically guess... -Toke
