Messages in this thread | | | Date | Thu, 26 Jan 2012 17:24:55 -0200 | From | Arnaldo Carvalho de Melo <> | Subject | Re: Fixing perf top --user shortcoming was: Re: [GIT PULL 0/9] perf/core improvements and fixes |
| |
Em Thu, Jan 26, 2012 at 07:32:23PM +0100, Ingo Molnar escreveu: > > * Arnaldo Carvalho de Melo <acme@infradead.org> wrote: > > > > > 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. > > It's probably privileged then - or at least not sufficiently > deprivileged. > > Skipping them ought to be the right solution - it's not like > such tasks tend to create a lot of overhead worth profiling. > They are also not debuggable via gdb so they are not part of the > user's development session and such.
Least convoluted way seems to be just to try to call sys_perf_event_open on then when building the thread list in thread_new__by_uid(), will try that after soccer :-)
/me vanishes
- Arnaldo
> > 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. > > Yeah. Maybe warn about them in verbose mode or such.
| |