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
Issues with ptrace_check_attach(),
- it does utrace_control(UTRACE_STOP).
This is wrong, ptrace_check_attach() must be passive,
while utrace_control(UTRACE_STOP) can actualy stop the
tracee.
This is not inherently problematic on its own. I'd say it's OK if
Dear Colleagues,
Due to numerous deadline extension requests from potential CISSE 2009
authors, the CISSE organizing committee has decided to extend the paper
submission deadline to 10/26/2009. Please note that this is a hard
deadline, so that the technical committees can perform their paper
I'm replying out of order. So I'm sorry I started rehashing some of this
same stuff in the other thread before reading where you'd already referred
to it.
What if the tracee reports a signal and stops, the tracer detaches
but does not wake it up because of SIGNAL_STOP_STOPPED ? In this
case
I think always-reply-to-all is the best policy ;)
For some people's mail-handling habits it makes a difference, so it is
always safest not to trim individuals. For me personally, I always
see the list copies just the same as the ones CC'd to me personally,
so I don't care to be in the CC list
