On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu [off-list ref] wrote:

On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:

quoted

Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:

quoted

On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra [off-list ref] wrote:

quoted

Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?

quoted

quoted

That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.

quoted

quoted

As might be clear; I don't actually know what the user-ABI is for
creating kprobes.

quoted

There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace interface to
define new kprobe events, and those events are treated as completely same as
tracepoint events. On the other hand, ebpf tries to define new probe event
via perf_event interface. Above one is that interface. IOW, it creates new kprobe.

Masami, any plans to make 'perf probe' use the perf_event_open()
interface for creating kprobes/uprobes?

Would you mean perf probe to switch to perf_event_open()?
No, perf probe is for setting up the ftrace probe events. I think we can add an
option to use perf_event_open(). But current kprobe creation from perf_event_open()
is separated from ftrace by design.

I guess we can extend event parser to understand kprobe directly. Instead of

	perf probe kernel_func
	perf stat/record -e probe:kernel_func ...

We can just do 

	perf stat/record -e kprobe:kernel_func ...

Thanks,
Song