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
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
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
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
---
kernel/ptrace.c |5 +
1 file changed, 5 insertions(+)
--- PU/kernel/ptrace.c~83_DETACH_SIGKILL2009-10-10 17:43:28.0
+0200
On Sat, 10 Oct 2009 18:17:12 +0200, Oleg Nesterov wrote:
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
attached testcase works for me on both:
kernel-2.6.31.1-48.fc12.x86_64
On 10/10, Jan Kratochvil wrote:
On Sat, 10 Oct 2009 18:17:12 +0200, Oleg Nesterov wrote:
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
attached testcase works for me on both:
