Re: Fixing perf top --user shortcoming was: Re: [GIT PULL 0/9]perf/core improvements and fixes

[Arnaldo Carvalho de Melo]

Em Thu, Jan 26, 2012 at 02:09:19PM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxx> 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?

IIRC one of them was a child of sshd, that runs as root and then changes
the child ownership to the user logging in.

I'll continue investigation but probably for now the first thing to do
is to just remove them from the thread_map when they return -EPERM.
 
> 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?

Yeah, that can be done, while debugging I'll emit a warning with the
resulting thread_map of "special tasks" to figure out what makes them
special.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/