[lkml]   [2008]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 20/24] perfmon: system calls interface

    On Mon, Dec 1, 2008 at 1:49 AM, Paul Mackerras <> wrote:
    > stephane eranian writes:
    >> Perfmon requires ptrace ONLY to stop the thread you want to operate
    >> on. For instance, to read the counters in a thread via pfm_read(), you
    >> need to have that thread stopped, so perfmon can extract the machine
    >> state safely.
    > What would happen if the thread wasn't stopped? Is it just that the
    > numbers would be inaccurate, or is there some kind of security
    > exposure?
    There are certain operations which cannot be performed, for instance

    As for read and write, sure you could never touch the PMU directly if you were
    not self-monitoring. But then there is question as what does the
    interface guarantee
    in terms of execution of the actions. With read, you'd have to say the
    interface does
    not guarantee the value returned is up-to-date. For applications which
    never context
    switch, for instance, there the values read from the software state
    maybe totally stale.

    > If it's just that the numbers would be inaccurate, then I don't think
    > the kernel needs to enforce it. The monitoring program *should*
    > ensure that the thread is stopped or blocked, one way or another, but
    > it could do that simply by sending a SIGSTOP to the thread. I don't
    > see that it would necessarily have to use ptrace.
    Because ptrace provides the additional guarantees, for instance,
    nobody can do a SIGCONT
    while you are operating on the ptraced thread, nobody else can do the
    Now, I don't think bad things could actually happen if a SIGCONT were
    to happen, because
    the context is locked during all operations and the context switch in
    routine tries to grab that
    lock. There may be difficulties if you hold the lock and then you need
    to release it for one operation
    and then you grab it again. There may be a couple of places where we do that.

    Also sending SIGSTOP is not enough to guarantee the thread is off of
    the CPU. You need to wait
    until it is actually off, i.e., all the state has been saved. I don't
    think you can test that from userland.

    Note that I am not arguing that we will have to use ptrace forever. In
    fact, utrace provides the mechanisms
    and the guarantees to avoid using ptrace alltogether. With utrace,
    applications would directly call into the
    kernel and then, if needed, the kernel would use utrace to stop the
    other thread. I have played with that several
    months ago and it worked fine. The problem is that utrace is still not in.

     \ /
      Last update: 2008-12-01 07:09    [W:0.030 / U:13.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site