Messages in this thread | | | Date | Tue, 26 Oct 2004 08:37:36 +0200 | From | Gerd Knorr <> | Subject | Re: ptrace bug in -rc2+ |
| |
On Mon, Oct 25, 2004 at 10:04:14PM -0700, Roland McGrath wrote: > Sorry it took a while for me to get back to you on this problem. > > > The introduction of the new TASK_TRACED state in 2.6.9-rc2 changed the > > behavior of the kernel in a IMHO buggy way. Sending a SIGKILL to a > > process which is traced _and_ stopped doesn't work any more. user mode > > linux kernels do that on shutdown, thats why I ran into this. > > This is a change that I explained when I posted the ptrace cleanup patches. > In general it is not safe to do any non-ptrace wakeup of a thread in > TASK_TRACED, because the waking thread could race with a ptrace call that > could be doing things like mucking directly with its kernel stack. AFAIK > noone has established that whatever clobberation ptrace can do to a running > thread is safe even if it will never return to user mode, so we can't allow > this even for SIGKILL.
Yes, some days later after studing the source code for some time (and learing alot about ptrace) I figured that myself as well ;)
> Your particular test program is the one special case where we could make > the SIGKILL work immediately: the caller of kill is the ptracer, so we know > noone else can be using ptrace at the same time. But I am not in favor of > adding this special case. If you use ptrace yourself, you should cope.
I agree, that can easily fixed in the app, either first SIGKILL then PTRACE_CONT, or just PTRACE_KILL directly ...
Gerd
-- #define printk(args...) fprintf(stderr, ## args) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |