perf: Block perf calls for system call tracepoints

arch/x86/entry/common.c +12 -0

index 3b2490b81918..e55cf9169a03 100644
@@ -60,6 +60,32 @@ static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch)
 	}
 }
 
+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+

arch/x86/entry/common.c +4 -0

+
+	current->perf_blocked = false;
+}
+

Quoted 25 lines · On Wed, 5 Dec 2018 17:05:02 +0100 Jiri Olsa <[email protected]> wrote:

arch/x86/entry/common.c +17 -0

index 3b2490b81918..e55cf9169a03 100644
@@ -60,6 +60,32 @@ static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch)
 	}
 }
 
+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_enter(&event_sys_enter, regs, regs->orig_ax);
+		} else {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_exit(regs);

arch/x86/entry/common.c static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch) · line 84

Quoted 5 lines

arch/x86/entry/common.c +5 -0

+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);
+		}
+	} while (current->perf_blocked_cnt);

I was thinking, if the process reading the perf buffer dies, how do we tell this task to continue on?

Adding support to specify 'block' bool in struct perf_event_attr

Quoted 1 line · Jiri Olsa

Adding support to specify 'block' bool in struct perf_event_attr

NAK for having _Bool in structures.

arch/x86/entry/common.c +15 -0

+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_enter(&event_sys_enter, regs, regs->orig_ax);
+		} else {

Quoted 20 lines · Jiri Olsa

arch/x86/entry/common.c +20 -0

+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_enter(&event_sys_enter, regs, regs->orig_ax);
+		} else {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_exit(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);

arch/x86/entry/common.c static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch) · line 87

Quoted 5 lines

arch/x86/entry/common.c +5 -0

+		}
+	} while (current->perf_blocked_cnt);
+
+	current->perf_blocked = false;
+}

I don't understand this.. why are we using schedule_timeout() and all that?

Quoted 21 lines · Peter Zijlstra

Quoted 20 lines · Jiri Olsa

arch/x86/entry/common.c +20 -0

+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_enter(&event_sys_enter, regs, regs->orig_ax);
+		} else {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_exit(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);

Quoted 8 lines

arch/x86/entry/common.c static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch) · line 87

Quoted 5 lines

arch/x86/entry/common.c +5 -0

+		}
+	} while (current->perf_blocked_cnt);
+
+	current->perf_blocked = false;
+}

I don't understand this.. why are we using schedule_timeout() and all that?

the idea is to block the process and try to deliver the event later

the ring buffer space is freed by user space process moving the tail pointer, so I can't see doing this other way than polling

Quoted 20 lines · Jiri Olsa

arch/x86/entry/common.c +20 -0

+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_enter(&event_sys_enter, regs, regs->orig_ax);
+		} else {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_exit(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);

arch/x86/entry/common.c static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch) · line 87

Quoted 5 lines

arch/x86/entry/common.c +5 -0

+		}
+	} while (current->perf_blocked_cnt);
+
+	current->perf_blocked = false;
+}

I don't understand this.. why are we using schedule_timeout() and all that?

Quoted 21 lines · Peter Zijlstra

Quoted 20 lines · Jiri Olsa

arch/x86/entry/common.c +20 -0

+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+	current->perf_blocked = true;
+
+	do {
+		schedule_timeout(100 * HZ);
+		current->perf_blocked_cnt = 0;
+
+		if (enter) {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_enter(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_enter(&event_sys_enter, regs, regs->orig_ax);
+		} else {
+			/* perf syscalls:* enter */
+			perf_trace_syscall_exit(regs);
+
+			/* perf raw_syscalls:* enter */
+			perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);

Quoted 8 lines

arch/x86/entry/common.c static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch) · line 87

Quoted 5 lines

arch/x86/entry/common.c +5 -0

+		}
+	} while (current->perf_blocked_cnt);
+
+	current->perf_blocked = false;
+}

I don't understand this.. why are we using schedule_timeout() and all that?

Urgh.. in fact, the more I look at this the more I hate it.

We want to block in __perf_output_begin(), but we cannot because both tracepoints and perf will have preemptability disabled down there.

So what we do is fail the event, fake the lost count and go all the way up that callstack, detect the failure and then poll-wait and retry.

And only do this for a few special events... *yuck*

Quoted 3 lines

I don't understand this.. why are we using schedule_timeout() and all that?

Urgh.. in fact, the more I look at this the more I hate it.

We want to block in __perf_output_begin(), but we cannot because both tracepoints and perf will have preemptability disabled down there.

So what we do is fail the event, fake the lost count and go all the way up that callstack, detect the failure and then poll-wait and retry.

And only do this for a few special events... *yuck*

Quoted 12 lines · On Thu, 6 Dec 2018 09:34:00 +0100 Peter Zijlstra <[email protected]> wrote:

Quoted 3 lines

I don't understand this.. why are we using schedule_timeout() and all that?

Urgh.. in fact, the more I look at this the more I hate it.

We want to block in __perf_output_begin(), but we cannot because both tracepoints and perf will have preemptability disabled down there.

So what we do is fail the event, fake the lost count and go all the way up that callstack, detect the failure and then poll-wait and retry.

Quoted 1 line

And only do this for a few special events... *yuck*

Since this is a special case, we should add a new option to the perf system call that, 1 states that it wants the traced process to block (and must have PTRACE permission to do so) and 2, after it reads from the buffer, it needs to check a bit that says "this process is blocked, please wake it up" and then do another perf call to kick the process to continue.

I really dislike the polling too. But because this is not a default case, and is a new feature, we can add more infrastructure to make it work properly, instead of trying to hack the current method into something that does something poorly.

-- Steve

Quoted 6 lines · On Thu, 6 Dec 2018 09:34:00 +0100 Peter Zijlstra <[email protected]> wrote:

Quoted 3 lines

I don't understand this.. why are we using schedule_timeout() and all that?

Urgh.. in fact, the more I look at this the more I hate it.

Quoted 7 lines

We want to block in __perf_output_begin(), but we cannot because both tracepoints and perf will have preemptability disabled down there.

So what we do is fail the event, fake the lost count and go all the way up that callstack, detect the failure and then poll-wait and retry.

And only do this for a few special events... *yuck*

Since this is a special case, we should add a new option to the perf system call that, 1 states that it wants the traced process to block (and must have PTRACE permission to do so) and 2, after it reads from the buffer, it needs to check a bit that says "this process is blocked, please wake it up" and then do another perf call to kick the process to continue.

I really dislike the polling too. But because this is not a default case, and is a new feature, we can add more infrastructure to make it work properly, instead of trying to hack the current method into something that does something poorly.

These patches give no justification *what*so*ever* for why we're doing ugly arse things like this. And why does this, whatever this is, need to be done in perf?

IOW, what problem are we solving ?

Quoted 4 lines · On Fri, 7 Dec 2018 09:58:39 +0100 Peter Zijlstra <[email protected]> wrote:

These patches give no justification *what*so*ever* for why we're doing ugly arse things like this. And why does this, whatever this is, need to be done in perf?

Quoted 1 line

IOW, what problem are we solving ?

I guess the cover letter should have had a link (or copy) of this:

http://lkml.kernel.org/r/[email protected]

Quoted 5 lines · On Fri, 7 Dec 2018 09:58:39 +0100 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines

These patches give no justification *what*so*ever* for why we're doing ugly arse things like this. And why does this, whatever this is, need to be done in perf?

Quoted 5 lines

Quoted 1 line

IOW, what problem are we solving ?

I guess the cover letter should have had a link (or copy) of this:

http://lkml.kernel.org/r/[email protected]

That doesn't even begin to explain. Who cares about strace and why? And why is it such a bad thing to loose the occasional record etc..

Em Fri, Dec 07, 2018 at 04:11:05PM +0100, Peter Zijlstra escreveu:

Quoted 7 lines · Steven Rostedt

Quoted 5 lines · On Fri, 7 Dec 2018 09:58:39 +0100 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines

These patches give no justification *what*so*ever* for why we're doing ugly arse things like this. And why does this, whatever this is, need to be done in perf?

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

IOW, what problem are we solving ?

I guess the cover letter should have had a link (or copy) of this:

http://lkml.kernel.org/r/[email protected]

That doesn't even begin to explain. Who cares about strace and why? And why is it such a bad thing to loose the occasional record etc..

The following almost addresses all the details for doing such a perf based strace tool (modulo signals), was started by Thomas a long time ago [1] and is in the tree for a long time, with BPF attached to the raw_syscalls:sys_{enter,exit} (that -e augmented_raw_syscalls.c thing that lives in tools/perf/examples/bpf now but would be put in place transparently and pre-compiled as augmented_raw_syscalls.o) to collect pointer contents without using ptrace:

For system wide stracing elliminating the feedback loop of your GUI components will most of the time work with the default ring buffer size and when it doesn't, you'll get things like that "LOST events!" message, and for such extreme cases, just use '-m' to bump the rb size some more.

# trace  --filter-pids 2279,1643

8793.640 ( 0.001 ms): cc1/19097 read(fd: 21, buf: 0x3ed6a13, count: 4096 ) = 0
LOST 34956 events!
9497.921 ( 0.006 ms): gcc/19180 openat(dfd: CWD, filename: 0x3115e20, flags: NOCTTY ) = -1 ENOENT No such file or directory

'trace' is just 'perf trace', perf has logic to see if argv[0] is 'trace', then it goes and does a 'perf trace'. The above case does't use bpf at all, gets details from /proc.

With bpf we get the 'filename' contents:

[root@seventh bpf]# trace -e augmented_raw_syscalls.c --filter-pids 2279,1643 <SNIP>

 19766.027 ( 0.003 ms): gcc/27524 openat(dfd: CWD, filename: /lib64/libz.so.1, flags: CLOEXEC           ) = 5
 19766.035 ( 0.001 ms): gcc/27524 fstat(fd: 5, statbuf: 0x7ffe9323e2a0                                  ) = 0
 19766.037 ( 0.003 ms): gcc/27524 mmap(len: 2187272, prot: EXEC|READ, flags: PRIVATE|DENYWRITE, fd: 5   ) = 0x7fa2df435000
 19766.042 ( 0.003 ms): gcc/27524 mprotect(start: 0x7fa2df44b000, len: 2093056                          ) = 0
 19766.046 ( 0.004 ms): gcc/27524 mmap(addr: 0x7fa2df64a000, len: 4096, prot: READ|WRITE, flags: PRIVATE|FIXED|DENYWRITE, fd: 5, off: 86016) = 0x7fa2df64a000

19766.051 ( 0.002 ms): gcc/27524 mmap(addr: 0x7fa2df64b000, len: 8, prot: READ|WRITE, flags: PRIVATE|FIXED|ANONYMOUS) = 0x7fa2df64b000
19766.057 ( 0.001 ms): gcc/27524 close(fd: 5 ) = 0
19766.062 ( 0.003 ms): gcc/27524 openat(dfd: CWD, filename: /lib64/libc.so.6, flags: CLOEXEC ) = 5
<SNIP>

Quoted 11 lines

[root@seventh bpf]# trace -e augmented_raw_syscalls.c --filter-pids 2279,1643 <SNIP>

 19766.027 ( 0.003 ms): gcc/27524 openat(dfd: CWD, filename: /lib64/libz.so.1, flags: CLOEXEC           ) = 5
 19766.035 ( 0.001 ms): gcc/27524 fstat(fd: 5, statbuf: 0x7ffe9323e2a0                                  ) = 0
 19766.037 ( 0.003 ms): gcc/27524 mmap(len: 2187272, prot: EXEC|READ, flags: PRIVATE|DENYWRITE, fd: 5   ) = 0x7fa2df435000
 19766.042 ( 0.003 ms): gcc/27524 mprotect(start: 0x7fa2df44b000, len: 2093056                          ) = 0
 19766.046 ( 0.004 ms): gcc/27524 mmap(addr: 0x7fa2df64a000, len: 4096, prot: READ|WRITE, flags: PRIVATE|FIXED|DENYWRITE, fd: 5, off: 86016) = 0x7fa2df64a000

19766.051 ( 0.002 ms): gcc/27524 mmap(addr: 0x7fa2df64b000, len: 8, prot: READ|WRITE, flags: PRIVATE|FIXED|ANONYMOUS) = 0x7fa2df64b000
19766.057 ( 0.001 ms): gcc/27524 close(fd: 5 ) = 0
19766.062 ( 0.003 ms): gcc/27524 openat(dfd: CWD, filename: /lib64/libc.so.6, flags: CLOEXEC ) = 5
<SNIP>

Right; and that is all nice. And exactly doesn't answer my question. Why do we care about those LOST entries so much that we have to do such horribly ugly things?

Esp. as you point out, they're clearly marked in the output and easily avoided by using a slightly larger buffer.

Quoted 7 lines · Steven Rostedt

Quoted 4 lines · On Fri, 7 Dec 2018 09:58:39 +0100 Peter Zijlstra <[email protected]> wrote:

These patches give no justification *what*so*ever* for why we're doing ugly arse things like this. And why does this, whatever this is, need to be done in perf?

Quoted 5 lines

Quoted 1 line

IOW, what problem are we solving ?

I guess the cover letter should have had a link (or copy) of this:

http://lkml.kernel.org/r/[email protected]

That doesn't even begin to explain. Who cares about strace and why? And why is it such a bad thing to loose the occasional record etc..

Quoted 12 lines · On Fri, 7 Dec 2018 16:11:05 +0100 Peter Zijlstra <[email protected]> wrote:

Quoted 11 lines · Steven Rostedt

Quoted 5 lines · On Fri, 7 Dec 2018 09:58:39 +0100 Peter Zijlstra <[email protected]> wrote:

These patches give no justification *what*so*ever* for why we're doing ugly arse things like this. And why does this, whatever this is, need to be done in perf?

IOW, what problem are we solving ?

I guess the cover letter should have had a link (or copy) of this:

Quoted 4 lines

Quoted 1 line

http://lkml.kernel.org/r/[email protected]

That doesn't even begin to explain. Who cares about strace and why? And why is it such a bad thing to loose the occasional record etc..

Who cares about strace? Do I really need to answer that? It's one of the most used tools for seeing what a program is doing.

Why do we care about lost events? Because strace records *all* events, as that's what it does and that's what it always has done. It would be a break in functionality (a regression) if it were to start losing events. I use strace to see everything that an application is doing.

When we discussed this at plumbers, Oracle people came to me and said how awesome it would be to run strace against their database accesses. The problem today is that strace causes such a large overhead that it isn't feasible to trace any high speed applications, especially if there are time restraints involved.

It's a tool I haven't used in years, given we have so many better tools around these days.

Quoted 5 lines

Why do we care about lost events? Because strace records *all* events, as that's what it does and that's what it always has done. It would be a break in functionality (a regression) if it were to start losing events. I use strace to see everything that an application is doing.

So make a new tool; break the expectation of all events. See if there's anybody that really cares.

Quoted 6 lines

When we discussed this at plumbers, Oracle people came to me and said how awesome it would be to run strace against their database accesses. The problem today is that strace causes such a large overhead that it isn't feasible to trace any high speed applications, especially if there are time restraints involved.

So have them run that perf thing acme pointed to.

So far nobody's made a good argument for why we cannot have LOST events.

Quoted 5 lines · On Sat, 8 Dec 2018 11:44:23 +0100 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines

Why do we care about lost events? Because strace records *all* events, as that's what it does and that's what it always has done. It would be a break in functionality (a regression) if it were to start losing events. I use strace to see everything that an application is doing.

Quoted 2 lines

So make a new tool; break the expectation of all events. See if there's anybody that really cares.

Basically you are saying, break strace and see if anyone notices?

Quoted 6 lines

Quoted 5 lines

When we discussed this at plumbers, Oracle people came to me and said how awesome it would be to run strace against their database accesses. The problem today is that strace causes such a large overhead that it isn't feasible to trace any high speed applications, especially if there are time restraints involved.

Quoted 3 lines

So have them run that perf thing acme pointed to.

So far nobody's made a good argument for why we cannot have LOST events.

If you don't see the use case, I'm not sure anyone can convince you. Again, I like the fact that when I do a strace of an application I know that all system calls that the application I'm tracing is recorded. I don't need to worry about what happened in the "lost events" space.

Quoted 11 lines · Steven Rostedt

Quoted 7 lines · Peter Zijlstra

Quoted 4 lines

Why do we care about lost events? Because strace records *all* events, as that's what it does and that's what it always has done. It would be a break in functionality (a regression) if it were to start losing events. I use strace to see everything that an application is doing.

So make a new tool; break the expectation of all events. See if there's anybody that really cares.

Basically you are saying, break strace and see if anyone notices?

Nah, give it a new name. Clearly mark this is a new tool.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

When we discussed this at plumbers, Oracle people came to me and said how awesome it would be to run strace against their database accesses. The problem today is that strace causes such a large overhead that it isn't feasible to trace any high speed applications, especially if there are time restraints involved.

Quoted 8 lines

Quoted 3 lines

So have them run that perf thing acme pointed to.

So far nobody's made a good argument for why we cannot have LOST events.

If you don't see the use case, I'm not sure anyone can convince you. Again, I like the fact that when I do a strace of an application I know that all system calls that the application I'm tracing is recorded. I don't need to worry about what happened in the "lost events" space.

You're the one pushing for this crap without _any_ justification. Why are you getting upset if I ask for some?

If people care so much, it shouldn't be hard to write up a coherent story on this, so far all I seem to get is: because it's always been like that.

Which really isn't much of an argument.

btw, I didn't ask for the implementation to be ugly.
You don't have to introduce polling into the kernel if you don't want to, userspace is perfectly capable of invoking wait4(2) in a loop. Just block the tracee, notify the tracer, and let it pick up the pieces.

Quoted 4 lines · On Thu, 13 Dec 2018 03:39:38 +0300, wrote:

btw, I didn't ask for the implementation to be ugly.
You don't have to introduce polling into the kernel if you don't want to, userspace is perfectly capable of invoking wait4(2) in a loop. Just block the tracee, notify the tracer, and let it pick up the pieces.

Note, there's been some discussion offlist to only have perf set a flag when it dropped an event and have the ptrace code do the heavy lifting of blocking the task and waking it back up. I think that would be a cleaner solution and wont muck with perf as badly.

Quoted 4 lines · On Thu, 13 Dec 2018 03:39:38 +0300 "Dmitry V. Levin" <[email protected]> wrote:

btw, I didn't ask for the implementation to be ugly.
You don't have to introduce polling into the kernel if you don't want to, userspace is perfectly capable of invoking wait4(2) in a loop. Just block the tracee, notify the tracer, and let it pick up the pieces.

Note, there's been some discussion offlist to only have perf set a flag when it dropped an event and have the ptrace code do the heavy lifting of blocking the task and waking it back up. I think that would be a cleaner solution and wont muck with perf as badly.

One, very big maybe, would be to add a new tracepoint type that includes a might_sleep() and we very carefully undo all the preempt_disable and go sleep where we should. That also gives the tracepoint crud the information it needs to publish the capability to userspace.

- the wakeups side is icky; the best I can come up with is making the data page R/O and single stepping on write fault, but that isn't multi-threading safe.

Quoted 8 lines · Steven Rostedt

Quoted 4 lines · On Thu, 13 Dec 2018 03:39:38 +0300 "Dmitry V. Levin" <[email protected]> wrote:

btw, I didn't ask for the implementation to be ugly.
You don't have to introduce polling into the kernel if you don't want to, userspace is perfectly capable of invoking wait4(2) in a loop. Just block the tracee, notify the tracer, and let it pick up the pieces.

Quoted 4 lines

Note, there's been some discussion offlist to only have perf set a flag when it dropped an event and have the ptrace code do the heavy lifting of blocking the task and waking it back up. I think that would be a cleaner solution and wont muck with perf as badly.

It's still really horrid -- the question is not if we can come up with something, anything, to make strace work. The question is if we can extend something in a sane and maintainable manner to allow this.

So there's a whole bunch of problems I see with all this, in no particular order:

- we cannot block when writing to the actual buffer, and have to unroll the callstack and bolt on the blocking manualy in a few specific sites. This is ugly, inconsistent and maintenance heavy.

- it only works for some 'magic' events that got the treatment, but not for many other you might expect it to work for with no real indication which and why.

- the wakeups side is icky; the best I can come up with is making the data page R/O and single stepping on write fault, but that isn't multi-threading safe.

Another alternative would be keeping the whole page R/O and using write(2) or an ioctl() to update the head pointer.

Again, if we're going to do this; it needs to be done well and consistent and not as a special hack to enable strace-like functionality. And without clean and sane solutions to the above I just don't see it happening.

Note that the first 2 points are equally true for ftrace; so I don't see how we could sanely add it there either.

One, very big maybe, would be to add a new tracepoint type that includes a might_sleep() and we very carefully undo all the preempt_disable and go sleep where we should. That also gives the tracepoint crud the information it needs to publish the capability to userspace.

kernel/events/core.c +6 -0

@@ -10461,6 +10484,19 @@ SYSCALL_DEFINE5(perf_event_open,
 			return -EINVAL;
 	}
 
+	if (attr.block) {
+		/*
+		 * Allow only syscall tracepoints, check for syscall class
+		 * is made in the tracepoint event_init callback.
+		 */
+		if (attr.type != PERF_TYPE_TRACEPOINT)

Quoted 10 lines · Jiri Olsa

kernel/events/core.c +6 -0

@@ -10461,6 +10484,19 @@ SYSCALL_DEFINE5(perf_event_open,
 			return -EINVAL;
 	}
 
+	if (attr.block) {
+		/*
+		 * Allow only syscall tracepoints, check for syscall class
+		 * is made in the tracepoint event_init callback.
+		 */
+		if (attr.type != PERF_TYPE_TRACEPOINT)

kernel/events/core.c SYSCALL_DEFINE5(perf_event_open, · line 10502

Quoted 10 lines

kernel/events/core.c +7 -0

+			return -EINVAL;
+
+		/* Allow to block only if we attach to a process. */
+		if (pid == -1)
+			return -EINVAL;
+	}
+
 	/* Only privileged users can get physical addresses */
 	if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
 	    perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))

That's fairly horrible and will, when copied, lead to a giant mess.

Please see the whole exclusion patch set here:

https://lkml.kernel.org/r/[email protected]

PERF_PMU_CAP_BLOCK sounds like something you'd want here.