Re: [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

On Fri, 10 Jan 2020 21:35:12 -0300
arnaldo.melo@gmail.com wrote:

[off-list ref],Jann Horn [off-list ref],Thomas Gleixner [off-list ref],Tvrtko Ursulin [off-list ref],Lionel Landwerlin [off-list ref],linux-kernel [off-list ref],"linux-security-module@vger.kernel.org" [off-list ref],"selinux@vger.kernel.org" [off-list ref],"intel-gfx@lists.freedesktop.org" [off-list ref],"bpf@vger.kernel.org" [off-list ref],"linux-parisc@vger.kernel.org" [off-list ref],"linuxppc-dev@lists.ozlabs.org" [off-list ref],"linux-perf-users@vger.kernel.org" [off-list ref],"linux-arm-kernel@lists.infradead.org" [off-list ref],"oprofile-list@lists.sf.net" [off-list ref]
From: Arnaldo Carvalho de Melo <acme@kernel.org>
Message-ID: [off-list ref]

On January 10, 2020 9:23:27 PM GMT-03:00, Song Liu [off-list ref] wrote:

quoted

quoted

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

wrote:

quoted

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

quoted

quoted

quoted

Again, this only allows attaching to previously created kprobes,

it does

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

define new kprobe events, and those events are treated as

completely same as

quoted

quoted

quoted

tracepoint events. On the other hand, ebpf tries to define new

probe event

quoted

quoted

quoted

via perf_event interface. Above one is that interface. IOW, it

creates new kprobe.

quoted

quoted

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

quoted

option to use perf_event_open(). But current kprobe creation from

perf_event_open()

quoted

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 ...

You took the words from my mouth, exactly, that is a perfect use case, an alternative to the 'perf probe' one of making a disabled event that then gets activated via record/stat/trace, in many cases it's better, removes the explicit probe setup case.

Ah, I got it. If the perf event parser just kicks perf's kprobe creation
interface, it will be easy. In that case, there should be following differences.

- perf * -e "kprobe":kernel_func will put a local (hidden) kprobe
  events. So ftrace user can not access it.
- perf * -e "kprobe":kernel_func may not support inline/function-body
  nor trace local variables etc.

Hm, if we support inline function via -e "kprobe" interface, we have to
expand perf_event_open() to support multi-probe event.

Thanks,

Regards, 

- Arnaldo

quoted

Thanks,
Song

-- 
Masami Hiramatsu [off-list ref]