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.