[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