lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 23 Mar 2016 11:41:29 +0100 From: Peter Zijlstra <peterz@...radead.org> To: Jiri Olsa <jolsa@...nel.org> Cc: Steven Rostedt <rostedt@...dmis.org>, lkml <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Arnaldo Carvalho de Melo <acme@...nel.org> Subject: Re: [PATCH 2/5] ftrace perf: Move exclude_kernel tracepoint check to init event On Wed, Mar 16, 2016 at 03:34:30PM +0100, Jiri Olsa wrote: > We suppress events with attr::exclude_kernel set when > the event is generated, so following capture will > give no warning but won't produce any data: > > $ sudo perf record -e sched:sched_switch:u ls > $ sudo /perf script | wc -l > 0 > > Checking the attr::exclude_(kernel|user) at the event > init time and failing right away for tracepoints from > uprobes/kprobes and native ones: > > $ sudo perf record -e sched:sched_switch:u ls > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (sched:sched_switch). > /bin/dmesg may provide additional information. > No CONFIG_PERF_EVENTS=y kernel support configured? > > $ sudo perf record -e probe:sys_read:u ls > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (probe:sys_read). > /bin/dmesg may provide additional information. > No CONFIG_PERF_EVENTS=y kernel support configured? > > $ ./perf record -e probe_ex:main:k ./ex > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (probe_ex:main). > /bin/dmesg may provide additional information. > No CONFIG_PERF_EVENTS=y kernel support configured? Not sure about this one. The previous behaviour suggests exclude_{user,kernel} is implemented, while the new behaviour says these flags are not implemented, which is a functional regression. That is, if all events are from kernel space, and we exclude all kernel events, 0 is the right answer not an error. Sure, with uprobes the situation is currently broken, but this isn't a fix.
Powered by blists - more mailing lists