On Wed, Dec 1, 2021 at 1:32 PM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > On Tue, Nov 30, 2021 at 10:53:58PM -0800, Andrii Nakryiko wrote: > > On Wed, Nov 24, 2021 at 12:41 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > Adding support to create multiple probes within single perf event. > > > This way we can associate single bpf program with multiple kprobes, > > > because bpf program gets associated with the perf event. > > > > > > The perf_event_attr is not extended, current fields for kprobe > > > attachment are used for multi attachment. > > > > I'm a bit concerned with complicating perf_event_attr further to > > support this multi-attach. For BPF, at least, we now have > > bpf_perf_link and corresponding BPF_LINK_CREATE command in bpf() > > syscall which allows much simpler and cleaner API to do this. Libbpf > > will actually pick bpf_link-based attachment if kernel supports it. I > > think we should better do bpf_link-based approach from the get go. > > > > Another thing I'd like you to keep in mind and think about is BPF > > cookie. Currently kprobe/uprobe/tracepoint allow to associate > > arbitrary user-provided u64 value which will be accessible from BPF > > program with bpf_get_attach_cookie(). With multi-attach kprobes this > > because extremely crucial feature to support, otherwise it's both > > expensive, inconvenient and complicated to be able to distinguish > > between different instances of the same multi-attach kprobe > > invocation. So with that, what would be the interface to specify these > > BPF cookies for this multi-attach kprobe, if we are going through > > perf_event_attr. Probably picking yet another unused field and > > union-izing it with a pointer. It will work, but makes the interface > > even more overloaded. While for LINK_CREATE we can just add another > > pointer to a u64[] with the same size as number of kfunc names and > > offsets. > > I'm not sure we could bypass perf event easily.. perhaps introduce > BPF_PROG_TYPE_RAW_KPROBE as we did for tracepoints or just new > type for multi kprobe attachment like BPF_PROG_TYPE_MULTI_KPROBE > that might be that way we'd have full control over the API Indeed. The existing kprobe prog type has this api: * Return: BPF programs always return an integer which is interpreted by * kprobe handler as: * 0 - return from kprobe (event is filtered out) * 1 - store kprobe event into ring buffer that part we cannot change. No one was using that filtering feature. It often was in a way. New MULTI_KPROBE prog type should not have it.
