Messages in this thread | | | Date | Thu, 26 Jan 2012 14:09:19 +0100 | From | Ingo Molnar <> | Subject | Re: Fixing perf top --user shortcoming was: Re: [GIT PULL 0/9] perf/core improvements and fixes |
| |
* Arnaldo Carvalho de Melo <acme@infradead.org> wrote:
> > So what does --uid do which perf record --pid 1234 wouldnt > > already do? By all means --uid ought to be a fancy way of > > doing a whole bunch of perf record --pid 1234 profiling > > sessions, at once. > > I stopped at the kernel, i.e. used what can be done with what > is available from the kernel right now, the diagnosis was sent > in private, but boils down to: > > +++ b/kernel/events/core.c > @@ -2636,7 +2636,8 @@ find_lively_task_by_vpid(pid_t vpid) > > /* Reuse ptrace permission checks for now. */ > err = -EACCES; > - if (!ptrace_may_access(task, PTRACE_MODE_READ)) > + if (perf_paranoid_tracepoint_raw() && > + !ptrace_may_access(task, PTRACE_MODE_READ)) > goto errout; > > return task; > > ptrace_may_access(task, PTRACE_MODE_READ) fails for some tasks > owned by the user because, IIRC, in __ptrace_may_access:
Which tasks are these, are they privileged in any sense?
If yes and if most of the 'real' tasks a user have can be profiled just fine then i think we should just skip the privileged tasks and not abort the profiling session?
Thanks,
Ingo
| |