> Damn, this PTRACE_KILL is so weird. Yes. It's useless. Not regressing on the expectations of stupid old programs that don't really know what it does is all that's required.
> Apart from that, what it should actually do? It should work like PTRACE_CONT,SIGKILL but the only error case is -ESRCH when you aren't the tracer and always returns 0 otherwise. That's the whole of its mandate. > If the tracee was STOPPED/TRACED, then it is equivalent to > PTRACE_CONT,SIGKILL. > Otherwise it has no effect except it can race with exit() and spoil > ->exit_code, > and wake_up_process() is not good if course. (I am talking about upstream). Correct. In job control stop (including one already turned into TASK_TRACED by a prior ptrace call), the resumption signal is ignored. So the only reliable effect at all is when it's in a proper ptrace stop that doesn't otherwise swallow signals (i.e. exactly PTRACE_CONT,SIGKILL that ignores liveness/stoppedness errors). In every other case it has no effect at best, so fixing that to "no effect at all" is just fine. > Please tell me what do you think, then I'll do other changes you suggested. In the old code, PTRACE_KILL can never fail once the initial attachedness test has passed. So: (void) ptrace_resume(child, engine, request, SIGKILL); ret = 0; /* Historical compatibility. */ is probably fine. Thanks, Roland