In-Reply-To: <[email protected]>
(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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
