From: arnaldo.melo@gmail.com To: Song Liu <songliubraving@fb.com>,Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, Peter Zijlstra <peterz@infradead.org>, "joonas.lahtinen@linux.intel.com" <joonas.lahtinen@linux.intel.com>, Will Deacon <will.deacon@arm.com>, Alexei Starovoitov <ast@kernel.org>, Stephane Eranian <eranian@google.com>, "james.bottomley@hansenpartnership.com" <james.bottomley@hansenpartnership.com>, Paul Mackerras <paulus@samba.org>, Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>, Alexey Budankov <alexey.budankov@linux.intel.com>, Igor Lubashev <ilubashe@akamai.com>, James Morris <jmorris@namei.org>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Serge Hallyn <serge@hallyn.com>, Robert Richter <rric@kernel.org>, "jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>, "rodrigo.vivi@intel.com" <rodrigo.vivi@intel.com>, Namhyung Kim <namhyung@kernel.org>, Kees@lists.ozlabs.org, Casey Schaufler <casey@schaufler-ca.com> Subject: Re: [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process Date: Fri, 10 Jan 2020 21:35:12 -0300 [thread overview] Message-ID: <5e191833.1c69fb81.8bc25.a88c@mx.google.com> (raw) In-Reply-To: <2B79131A-3F76-47F5-AAB4-08BCA820473F@fb.com> <keescook@chromium.org>,Jann Horn <jannh@google.com>,Thomas Gleixner <tglx@linutronix.de>,Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,Lionel Landwerlin <lionel.g.landwerlin@intel.com>,linux-kernel <linux-kernel@vger.kernel.org>,"linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>,"selinux@vger.kernel.org" <selinux@vger.kernel.org>,"intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>,"bpf@vger.kernel.org" <bpf@vger.kernel.org>,"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,"linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>,"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>,"oprofile-list@lists.sf.net" <oprofile-list@lists.sf.net> From: Arnaldo Carvalho de Melo <acme@kernel.org> Message-ID: <A7F0BF73-9189-44BA-9264-C88F2F51CBF3@kernel.org> On January 10, 2020 9:23:27 PM GMT-03:00, Song Liu <songliubraving@fb.com> wrote: > > >> On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu <mhiramat@kernel.org> >wrote: >> >> On Fri, 10 Jan 2020 13:45:31 -0300 >> Arnaldo Carvalho de Melo <acme@kernel.org> wrote: >> >>> Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu: >>>> On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra ><peterz@infradead.org> wrote: >>>>> Again, this only allows attaching to previously created kprobes, >it does >>>>> not allow creating kprobes, right? >>> >>>>> That is; I don't think CAP_SYS_PERFMON should be allowed to create >>>>> kprobes. >>> >>>>> As might be clear; I don't actually know what the user-ABI is for >>>>> creating kprobes. >>> >>>> 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 ... 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. Regards, - Arnaldo > >Thanks, >Song
WARNING: multiple messages have this Message-ID (diff)
From: arnaldo.melo@gmail.com To: Song Liu <songliubraving@fb.com>,Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, Peter Zijlstra <peterz@infradead.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Will Deacon <will.deacon@arm.com>, Alexei Starovoitov <ast@kernel.org>, Stephane Eranian <eranian@google.com>, "james.bottomley@hansenpartnership.com" <james.bottomley@hansenpartnership.com>, Paul Mackerras <paulus@samba.org>, Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>, Michael Ellerman <mpe@ellerman.id.au>, Igor Lubashev <ilubashe@akamai.com>, James Morris <jmorris@namei.org>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Serge Hallyn <serge@hallyn.com>, Robert Richter <rric@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Kees@freedesktop.org, Casey Schaufler <casey@schaufler-ca.com> Subject: Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process Date: Fri, 10 Jan 2020 21:35:12 -0300 [thread overview] Message-ID: <5e191833.1c69fb81.8bc25.a88c@mx.google.com> (raw) In-Reply-To: <2B79131A-3F76-47F5-AAB4-08BCA820473F@fb.com> <keescook@chromium.org>,Jann Horn <jannh@google.com>,Thomas Gleixner <tglx@linutronix.de>,Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,Lionel Landwerlin <lionel.g.landwerlin@intel.com>,linux-kernel <linux-kernel@vger.kernel.org>,"linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>,"selinux@vger.kernel.org" <selinux@vger.kernel.org>,"intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>,"bpf@vger.kernel.org" <bpf@vger.kernel.org>,"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,"linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>,"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>,"oprofile-list@lists.sf.net" <oprofile-list@lists.sf.net> From: Arnaldo Carvalho de Melo <acme@kernel.org> Message-ID: <A7F0BF73-9189-44BA-9264-C88F2F51CBF3@kernel.org> On January 10, 2020 9:23:27 PM GMT-03:00, Song Liu <songliubraving@fb.com> wrote: > > >> On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu <mhiramat@kernel.org> >wrote: >> >> On Fri, 10 Jan 2020 13:45:31 -0300 >> Arnaldo Carvalho de Melo <acme@kernel.org> wrote: >> >>> Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu: >>>> On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra ><peterz@infradead.org> wrote: >>>>> Again, this only allows attaching to previously created kprobes, >it does >>>>> not allow creating kprobes, right? >>> >>>>> That is; I don't think CAP_SYS_PERFMON should be allowed to create >>>>> kprobes. >>> >>>>> As might be clear; I don't actually know what the user-ABI is for >>>>> creating kprobes. >>> >>>> 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 ... 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. Regards, - Arnaldo > >Thanks, >Song _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-01-11 7:57 UTC|newest] Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-18 9:16 [PATCH v4 0/7] Introduce CAP_SYS_PERFMON to secure system performance monitoring and observability Alexey Budankov 2019-12-18 9:16 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:16 ` Alexey Budankov 2019-12-18 9:16 ` Alexey Budankov 2019-12-18 9:16 ` Alexey Budankov 2019-12-18 9:24 ` [PATCH v4 1/9] capabilities: introduce CAP_SYS_PERFMON to kernel and user space Alexey Budankov 2019-12-18 9:24 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:24 ` Alexey Budankov 2019-12-18 9:24 ` Alexey Budankov 2019-12-18 9:24 ` Alexey Budankov 2019-12-18 19:56 ` Stephen Smalley 2019-12-18 19:56 ` [Intel-gfx] " Stephen Smalley 2019-12-18 19:56 ` Stephen Smalley 2019-12-18 19:56 ` Stephen Smalley 2019-12-18 19:56 ` Stephen Smalley 2019-12-28 3:53 ` Serge E. Hallyn 2019-12-28 3:53 ` [Intel-gfx] " Serge E. Hallyn 2019-12-28 3:53 ` Serge E. Hallyn 2019-12-28 3:53 ` Serge E. Hallyn 2020-01-13 20:25 ` Song Liu 2020-01-13 20:25 ` [Intel-gfx] " Song Liu 2020-01-13 20:25 ` Song Liu 2020-01-13 20:25 ` Song Liu 2019-12-18 9:25 ` [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process Alexey Budankov 2019-12-18 9:25 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:25 ` Alexey Budankov 2019-12-18 9:25 ` Alexey Budankov 2019-12-18 9:25 ` Alexey Budankov 2020-01-08 16:07 ` Peter Zijlstra 2020-01-08 16:07 ` [Intel-gfx] " Peter Zijlstra 2020-01-08 16:07 ` Peter Zijlstra 2020-01-08 16:07 ` Peter Zijlstra 2020-01-08 16:07 ` Peter Zijlstra 2020-01-09 11:36 ` Alexey Budankov 2020-01-09 11:36 ` [Intel-gfx] " Alexey Budankov 2020-01-09 11:36 ` Alexey Budankov 2020-01-09 11:36 ` Alexey Budankov 2020-01-09 11:36 ` Alexey Budankov 2020-01-10 14:02 ` Peter Zijlstra 2020-01-10 14:02 ` [Intel-gfx] " Peter Zijlstra 2020-01-10 14:02 ` Peter Zijlstra 2020-01-10 14:02 ` Peter Zijlstra 2020-01-10 15:52 ` Masami Hiramatsu 2020-01-10 15:52 ` [Intel-gfx] " Masami Hiramatsu 2020-01-10 15:52 ` Masami Hiramatsu 2020-01-10 15:52 ` Masami Hiramatsu 2020-01-10 16:45 ` Arnaldo Carvalho de Melo 2020-01-10 16:45 ` [Intel-gfx] " Arnaldo Carvalho de Melo 2020-01-10 16:45 ` Arnaldo Carvalho de Melo 2020-01-10 16:45 ` Arnaldo Carvalho de Melo 2020-01-10 23:47 ` Masami Hiramatsu 2020-01-10 23:47 ` [Intel-gfx] " Masami Hiramatsu 2020-01-10 23:47 ` Masami Hiramatsu 2020-01-10 23:47 ` Masami Hiramatsu 2020-01-11 0:23 ` Song Liu 2020-01-11 0:23 ` [Intel-gfx] " Song Liu 2020-01-11 0:23 ` Song Liu 2020-01-11 0:23 ` Song Liu 2020-01-11 0:35 ` arnaldo.melo [this message] 2020-01-11 0:35 ` [Intel-gfx] " arnaldo.melo 2020-01-11 9:57 ` Alexey Budankov 2020-01-13 20:39 ` Song Liu 2020-01-14 3:25 ` Masami Hiramatsu 2020-01-14 5:17 ` Alexei Starovoitov 2020-01-14 9:47 ` Alexey Budankov 2020-01-14 18:06 ` Alexei Starovoitov 2020-01-14 18:50 ` Alexey Budankov 2020-01-15 1:52 ` Alexei Starovoitov 2020-01-15 5:15 ` Alexey Budankov 2020-04-01 20:50 ` Alexey Budankov 2020-04-03 13:55 ` Alexey Budankov 2020-04-03 13:56 ` Alexey Budankov 2020-01-15 9:45 ` Masami Hiramatsu 2020-01-15 12:11 ` Alexey Budankov 2020-01-14 12:04 ` Masami Hiramatsu 2020-01-12 1:44 ` Masami Hiramatsu 2020-01-12 1:44 ` [Intel-gfx] " Masami Hiramatsu 2020-01-12 1:44 ` Masami Hiramatsu 2020-01-10 16:41 ` Alexey Budankov 2020-01-10 16:41 ` [Intel-gfx] " Alexey Budankov 2020-01-10 16:41 ` Alexey Budankov 2020-01-10 16:41 ` Alexey Budankov 2020-01-10 17:34 ` Alexey Budankov 2020-01-10 17:34 ` [Intel-gfx] " Alexey Budankov 2020-01-10 17:34 ` Alexey Budankov 2020-01-10 17:34 ` Alexey Budankov 2020-04-01 20:49 ` Alexey Budankov 2020-04-03 14:28 ` Alexey Budankov 2019-12-18 9:26 ` [PATCH v4 3/9] perf tool: extend Perf tool with CAP_SYS_PERFMON capability support Alexey Budankov 2019-12-18 9:26 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:26 ` Alexey Budankov 2019-12-18 9:26 ` Alexey Budankov 2019-12-18 9:26 ` Alexey Budankov 2019-12-18 9:27 ` [PATCH v4 4/9] drm/i915/perf: open access for CAP_SYS_PERFMON privileged process Alexey Budankov 2019-12-18 9:27 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:27 ` Alexey Budankov 2019-12-18 9:27 ` Alexey Budankov 2019-12-18 9:27 ` Alexey Budankov 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-19 9:10 ` [Intel-gfx] " Lionel Landwerlin 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-18 9:28 ` [PATCH v4 5/9] trace/bpf_trace: " Alexey Budankov 2019-12-18 9:28 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2020-01-13 20:47 ` Song Liu 2020-01-13 20:47 ` [Intel-gfx] " Song Liu 2020-01-13 20:47 ` Song Liu 2020-01-13 20:47 ` Song Liu 2019-12-18 9:28 ` [PATCH v4 6/9] powerpc/perf: " Alexey Budankov 2019-12-18 9:28 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:29 ` [PATCH v4 7/9] parisc/perf: " Alexey Budankov 2019-12-18 9:29 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:29 ` Alexey Budankov 2019-12-18 9:29 ` Alexey Budankov 2019-12-18 9:29 ` Alexey Budankov 2020-01-27 8:52 ` Helge Deller 2020-01-27 8:52 ` [Intel-gfx] " Helge Deller 2020-01-27 8:52 ` Helge Deller 2020-01-27 8:52 ` Helge Deller 2020-01-27 8:52 ` Helge Deller 2019-12-18 9:30 ` [PATCH v4 8/9] drivers/perf: " Alexey Budankov 2019-12-18 9:30 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:30 ` Alexey Budankov 2019-12-18 9:30 ` Alexey Budankov 2019-12-18 9:30 ` Alexey Budankov 2020-01-17 10:51 ` Will Deacon 2020-01-17 10:51 ` [Intel-gfx] " Will Deacon 2020-01-17 10:51 ` Will Deacon 2020-01-17 10:51 ` Will Deacon 2020-01-17 21:33 ` Alexey Budankov 2020-01-17 21:33 ` [Intel-gfx] " Alexey Budankov 2020-01-17 21:33 ` Alexey Budankov 2020-01-17 21:33 ` Alexey Budankov 2020-01-18 18:48 ` Alexey Budankov 2020-01-18 18:48 ` Alexey Budankov 2019-12-18 9:31 ` [PATCH v4 9/9] drivers/oprofile: " Alexey Budankov 2019-12-18 9:31 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:31 ` Alexey Budankov 2019-12-18 9:31 ` Alexey Budankov 2019-12-18 9:31 ` Alexey Budankov 2019-12-18 10:11 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce CAP_SYS_PERFMON to secure system performance monitoring and observability (rev3) Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5e191833.1c69fb81.8bc25.a88c@mx.google.com \ --to=arnaldo.melo@gmail.com \ --cc=Kees@lists.ozlabs.org \ --cc=ak@linux.intel.com \ --cc=alexander.shishkin@linux.intel.com \ --cc=alexey.budankov@linux.intel.com \ --cc=ast@kernel.org \ --cc=casey@schaufler-ca.com \ --cc=eranian@google.com \ --cc=ilubashe@akamai.com \ --cc=james.bottomley@hansenpartnership.com \ --cc=jani.nikula@linux.intel.com \ --cc=jmorris@namei.org \ --cc=jolsa@redhat.com \ --cc=joonas.lahtinen@linux.intel.com \ --cc=mark.rutland@arm.com \ --cc=mhiramat@kernel.org \ --cc=mingo@redhat.com \ --cc=namhyung@kernel.org \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=rodrigo.vivi@intel.com \ --cc=rric@kernel.org \ --cc=serge@hallyn.com \ --cc=songliubraving@fb.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.