Re: ptrace bugs and related problems

[Chuck Ebbert <76306.1226@compuserve.com>]

In-Reply-To: <20060728034741.GA3372@nevyn.them.org>

(cc: trimmed)

On Thu, 27 Jul 2006 23:47:41 -0400, Daniel Jacobowitz wrote:
> 
> > In do_fork, the result of fork_traceflag is assigned
> > to the "trace" variable. Note that PT_TRACE_VFORK_DONE
> > does not cause "trace" to be non-zero.
> > 
> > Then we hit this code:
> > 
> >                if (unlikely (trace)) {
> >                        current->ptrace_message = nr;
> >                        ptrace_notify ((trace << 8) | SIGTRAP);
> >                }
> > 
> > That doesn't run. The ptrace_message is thus not set when
> > ptrace_notify is called to send the PTRACE_EVENT_VFORK_DONE
> > message. You get random stale data from a previous message.
> 
> Why do you want the message data anyway?
> 
> FORK/VFORK/CLONE events have a message: it says what the new process's
> PID is.  VFORK_DONE doesn't have a message, because it only indicates
> that the current process is about to resume; it's an event that only
> has one process associated with it.
> 
> I really don't think this is a bug.

Maybe not a bug, but this would be a nice enhancement.  It would cost
exactly one line of code.  I looked at user code I had written and it
assumed the message was available (it was, because I was also tracing
EVENT_VFORK and it happens to be left over from that.)  If we make this
a part of the API, future kernel changes wouldn't break this (erroneous)
assumption, which otherwise might give someone a nasty surprise in
currently-working code.

Otherwise we should zero it out and see what breaks. :)

-- 
Chuck

-
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/