[PATCH 122] ptrace_request(PTRACE_KILL) should not(?) return -ESRCH
Roland McGrath
roland at redhat.com
Fri Oct 30 07:36:46 UTC 2009
> 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
More information about the utrace-devel
mailing list