On Wed, Feb 16, 2022 at 10:27:19AM -0800, Andrii Nakryiko wrote:
SNIP
> >
> > hi,
> > tying to kick things further ;-) I was thinking about bpf side of this
> > and we could use following interface:
> >
> > enum bpf_attach_type {
> > ...
> > BPF_TRACE_KPROBE_MULTI
> > };
> >
> > enum bpf_link_type {
> > ...
> > BPF_LINK_TYPE_KPROBE_MULTI
> > };
> >
> > union bpf_attr {
> >
> > struct {
> > ...
> > struct {
> > __aligned_u64 syms;
> > __aligned_u64 addrs;
> > __aligned_u64 cookies;
> > __u32 cnt;
> > __u32 flags;
> > } kprobe_multi;
> > } link_create;
> > }
> >
> > because from bpf user POV it's new link for attaching multiple kprobes
> > and I agree new 'fprobe' type name in here brings more confusion, using
> > kprobe_multi is straightforward
> >
> > thoguhts?
>
> I think this makes sense. We do need new type of link to store ip ->
> cookie mapping anyways.
>
> Is there any chance to support this fast multi-attach for uprobe? If
> yes, we might want to reuse the same link for both (so should we name
> it more generically? on the other hand BPF program type for uprobe is
> BPF_PROG_TYPE_KPROBE anyway, so keeping it as "kprobe" also would be
> consistent with what we have today).
>
> But yeah, the main question is whether there is something preventing
> us from supporting multi-attach uprobe as well? It would be really
> great for USDT use case.
I need to check with uprobes, my understanding ends at perf/trace
code calling uprobe_register ;-)
maybe I should first try if uprobes suffer the same performance issue
I'll send another version with above interface, because there's
tons of other fixes, and by the time for next version we might
have answer for the interface change
jirka
