[lkml]   [2012]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fixing perf top --user shortcoming was: Re: [GIT PULL 0/9] perf/core improvements and fixes

    * Arnaldo Carvalho de Melo <> 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

    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.

    > 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.

    > > 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.

    Ok, sounds great!



     \ /
      Last update: 2012-01-26 19:35    [W:0.020 / U:10.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site