On Tue, Jun 08, 2021 at 08:42:32AM -0700, Alexei Starovoitov wrote: > On Sat, Jun 5, 2021 at 4:11 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > Adding support to attach multiple functions to tracing program > > by using the link_create/link_update interface. > > > > Adding multi_btf_ids/multi_btf_ids_cnt pair to link_create struct > > API, that define array of functions btf ids that will be attached > > to prog_fd. > > > > The prog_fd needs to be multi prog tracing program (BPF_F_MULTI_FUNC). > > > > The new link_create interface creates new BPF_LINK_TYPE_TRACING_MULTI > > link type, which creates separate bpf_trampoline and registers it > > as direct function for all specified btf ids. > > > > The new bpf_trampoline is out of scope (bpf_trampoline_lookup) of > > standard trampolines, so all registered functions need to be free > > of direct functions, otherwise the link fails. > > Overall the api makes sense to me. > The restriction of multi vs non-multi is too severe though. > The multi trampoline can serve normal fentry/fexit too. so multi trampoline gets called from all the registered functions, so there would need to be filter for specific ip before calling the standard program.. single cmp/jnz might not be that bad, I'll check > If ip is moved to the end (instead of start) the trampoline > will be able to call into multi and normal fentry/fexit progs. Right? > we could just skip ip arg when generating entry for normal programs and start from first argument address for %rdi and it'd need to be transparent for current trampolines user API, so I wonder there will be some hiccup ;-) let's see thanks, jirka
