[lkml]   [2012]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ptrace.2: PTRACE_KILL needs a stopped process too
    On Sunday 22 April 2012 16:04:59 Oleg Nesterov wrote:
    > On 04/23, Michael Kerrisk (man-pages) wrote:
    > > [widening CC]
    > add more CC's
    > > The man page says "For requests other than PTRACE_KILL,
    > Argh, PTRACE_KILL again.
    > You know, I simply do not know what it was supposed to do. I can only
    > see what the code actually does.
    > > the child process
    > > must be stopped."
    > Yes and no.
    > Yes, ptrace(PTRACE_KILL) "succeeds" even if the tracee is not stopped.
    > No, it has no effect if the tracee is not stopped.
    > All I can say is: PTRACE_KILL should never exist. If you want to kill
    > the tracee, you can do kill(SIGKILL).
    > Roughly, ptrace(PTRACE_KILL) is equal to ptrace(PTRACE_CONT, SIGKILL)
    > except it always returns 0.
    > > If the man page is describing actual intended kernel behavior, then it's
    > > a fairly long-standing kernel bug.
    > Perhaps. May be it should simply do kill(SIGKILL), but then it is not
    > clear why do we have PTRACE_KILL. And once again, I was never able to
    > understand the supposed behaviour.
    > Personally, I think we should fix the documentation. And imho the only
    > possible fix is to add this note: do not ever use PTRACE_KILL.

    probably not that big of a deal, but the reason i like using
    ptrace(PTRACE_KILL) over a raw kill() is that you are less likely to kill the
    wrong process by accident. maybe not that big of a deal in practice though.
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2012-05-09 21:41    [W:0.025 / U:0.204 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site