Re: [PATCH 122] ptrace_request(PTRACE_KILL) should not(?) return -ESRCH
Just noticed I didn't reply to this message, On 10/30, Roland McGrath wrote: 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. Yes, but utrace-ptrace does a lot more in ptrace_resume() compared to upstream. If the tracee is not stopped, then ptrace_resume() can race with the tracee in many ways. This is mostly harmless, I think, but still I did if (task_is_traced(child)) ptrace_resume(PTRACE_CONT, SIGKILL); ret = 0; Oleg.
Re: [PATCH 122] ptrace_request(PTRACE_KILL) should not(?) return -ESRCH
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
