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. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
