[PATCH 83] ptrace(DETACH, SIGKILL) should really kill the tracee

[Oleg Nesterov]

On 10/11, Roland McGrath wrote:
>
> > Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
> >
> > My guess: this should really kill the tracee asap, hence this patch.
>
> As far as killing, it is no more reliable than PTRACE_CONT,SIGKILL.
> i.e., will fail if it's not stopped, will be dropped on the floor if
> stopped at PTRACE_EVENT_EXEC et al.  So I would not especially try to make
> it any more reliable than that, especially if it takes a special case
> kludge like that.

OK, good. please ignore this patch then.

> For "make it die now", I have been advising people for years to just use
> plain kill(,SIGKILL).  That is the one thing we have worked the longest and
> most consistently to keep reliable in making things really die really soon.

Yes!

> The one thing that anyone using PTRACE_DETACH,SIGKILL does perhaps expect
> is that the detaching and killing are atomic.  That is, it's not possible
> for another thread in the tracer's process to get the WIFEXITED wait result
> for the tracee.  Conversely, that race is possible if the tracer does:
> 	kill(pid, SIGKILL);
> 	ptrace(PTRACE_DETACH, pid, anything);

I guess you mean that tracee->real_parent doesn't belong to tracer's
thread-group.

> (And a tracer doesn't want to do them in the other order if it wants to be
> sure to go from stopped->dead with no chance of running more user code.)
> So IMHO that is the only special wrinkle of PTRACE_DETACH,SIGKILL we need
> to worry about for compatibility.  In other senses it needs to work no
> better or different from PTRACE_CONT,SIGKILL.

OK. then we don't to complicate the code.

Oleg.