[lkml]   [2012]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ptrace.2: PTRACE_KILL needs a stopped process too
    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.


     \ /
      Last update: 2012-04-22 22:57    [W:0.022 / U:11.876 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site