lkml.org 
[lkml]   [2012]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2012-01-26 14:13    [W:0.328 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site