Messages in this thread | | | Date | Fri, 28 Jul 2006 16:07:56 -0400 | From | Chuck Ebbert <> | Subject | Re: ptrace bugs and related problems |
| |
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/
| |