From: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
To: Arnaldo Carvalho de Melo <acme@kernel.com>, Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@kernel.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
linux-kernel@vger.kernel.org
Subject: [BUG] perf stat: events inheritance can break task targets
Date: Mon, 07 Jul 2014 20:41:57 +0400 [thread overview]
Message-ID: <874myt86ju.wl%yarygin@linux.vnet.ibm.com> (raw)
perf stat can block pthread_create() for a multithreaded userspace
process (i.e. qemu) when:
- process is running with non-root privileges
- perf stat is running as root with trace events in -e option
- it is attached to the process's pid.
Here is a simple test scenario:
~$ cat test.c
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <string.h>
#define THREADS 50
static pthread_t threads[THREADS];
void *loop()
{
while(1);
}
int main()
{
for (int i = 0; i < THREADS; i++) {
int err = pthread_create(&threads[i], NULL, loop, 0);
if (!err)
printf("thread created: %i\n", i);
else
printf("couldn't create thread %i: %s\n", i, strerror(err));
sleep(1);
}
return 0;
}
~$ gcc test.c -lpthread -std=c99 -o test
~$ ./test
thread created: 0
thread created: 1
# now perf is running:
# ~$ sudo perf stat -e "kvm:*" -p `pidof test`
couldn't create thread 2: Operation not permitted
couldn't create thread 3: Operation not permitted
couldn't create thread 4: Operation not permitted
# here is perf was stopped
thread created: 5
thread created: 6
^C
When perf is running, every invoke of pthread_create() returns -EPERM.
On the kernel side, copy_process() creates a task, scheduled it,
than perf_event_init_task() (kernel/events/core.c) returns an error,
and the kernel cleans task's resources.
It looks like child process doesn't have access to trace events,
so perf_trace_event_perm() (kernel/trace/trace_event_perf.c)
returns -EPERM:
static int perf_trace_event_perm(struct ftrace_event_call *tp_event,
struct perf_event *p_event)
{
...
/*
* ...otherwise raw tracepoint data can be a severe data leak,
* only allow root to have these.
*/
if (perf_paranoid_tracepoint_raw() && !capable(CAP_SYS_ADMIN))
return -EPERM;
...
}
If we explicitly use the --no-inherit option, payload wouldn't die.
next reply other threads:[~2014-07-07 16:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-07 16:41 Alexander Yarygin [this message]
2014-07-07 17:00 ` Jiri Olsa
2014-07-07 19:46 ` Peter Zijlstra
2014-07-08 6:59 ` Jiri Olsa
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=874myt86ju.wl%yarygin@linux.vnet.ibm.com \
--to=yarygin@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.com \
--cc=borntraeger@de.ibm.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome