Re: ptrace bug in -rc2+

[Gerd Knorr <kraxel@bytesex.org>]

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)