On Fri, 18 Feb 2022 18:10:08 -0800 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Thu, Feb 17, 2022 at 8:07 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > On Thu, 17 Feb 2022 14:01:30 -0800 > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > > > 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? > > > > > > > > There is no interface to do that but also there is no limitation to > > > > expand uprobes. For the kprobes, there are some limitations for the > > > > function entry because it needs to share the space with ftrace. So > > > > I introduced fprobe for easier to use. > > > > > > > > > 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). > > > > > > > > Hmm, I'm not sure why BPF made such design choice... (Uprobe needs > > > > the target program.) > > > > > > > > > > We've been talking about sleepable uprobe programs, so we might need > > > to add uprobe-specific program type, probably. But historically, from > > > BPF point of view there was no difference between kprobe and uprobe > > > programs (in terms of how they are run and what's available to them). > > > From BPF point of view, it was just attaching BPF program to a > > > perf_event. > > > > Got it, so that will reuse the uprobe_events in ftrace. But I think > > the uprobe requires a "path" to the attached binary, how is it > > specified? > > > > > > > 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. > > > > > > > > Ah, for the USDT, it will be useful. But since now we will have "user-event" > > > > which is faster than uprobes, we may be better to consider to use it. > > > > > > Any pointers? I'm not sure what "user-event" refers to. > > > > Here is the user-events series, which allows user program to define > > raw dynamic events and it can write raw event data directly from > > user space. > > > > https://lore.kernel.org/all/20220118204326.2169-1-beaub@xxxxxxxxxxxxxxxxxxx/ > > Is this a way for user space to inject user bytes into kernel events? Yes, it is. > What is the use case? This is like trace_marker but more ftrace/perf friendly version. The trace_marker can only send a user string, and the kernel can not parse it. Thus, the traced data will be shown in the trace buffer, but the event filter, event trigger, histogram etc didn't work with trace_marker. On the other hand, the user-events allows user-space defines new events with various arguments with types, and the application can send the formatted raw data to the kernel. Thus the kernel can apply event filter, event trigger and histograms on those events as same as other kernel defined events. This will be helpful for users to push their own data as events of ftrace and perf (and eBPF I think) so that they can use those tracing tools to analyze both of their events and kernel events. :-) Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
