Date: Tue, 18 Dec 2001 16:31:00 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: RE: Is this a bug in the fork() code? Message-ID: <XFMail.011218163100.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0112181553140.36281-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-Dec-01 Julian Elischer wrote:
> Near the end of fork1():
> /*
> * If RFSTOPPED not requested, make child runnable and add to
> * run queue.
> */
> microtime(&(p2->p_stats->p_start));
> p2->p_acflag = AFORK;
> if ((flags & RFSTOPPED) == 0) {
> mtx_lock_spin(&sched_lock);
> p2->p_stat = SRUN; /* XXXKSE */
> setrunqueue(td2);
> mtx_unlock_spin(&sched_lock);
> }
>
>
>
> note that it may have made itself only a child of init.....
>
>
> later at the very end of fork1():
>
> /*
> * Return child proc pointer to parent.
> */
> *procp = p2;
> return (0);
> }
>
>
>
> now, what is to say that the process has not exitted by this stage, and
> been reeped by init (on SMP)
> particularly since between the two is:
>
> /*
> * Preserve synchronization semantics of vfork. If waiting for
> * child to exec or exit, set P_PPWAIT on child, and sleep on our
> * proc (in case of exit).
> */
> PROC_LOCK(p2);
> while (p2->p_flag & P_PPWAIT)
> msleep(p1, &p2->p_mtx, PWAIT, "ppwait", 0);
> PROC_UNLOCK(p2);
>
> It may be that due to some semantics of teh fork calls
> you cannot have P_PPWAIT and a process queued to run on the other
> processor while reparented to init(1) but I can't see it..
> the result would be that the return value MIGHT be teh pid
> of a totally different process if the proc structure had been re-used.
>
> Alternatively I could have some good weed here...
Note that fork1() is only called indirectly from syscalls. The only one for
which this can happen is if someone does rfork(.., RFNOWAIT | RFPPWAIT).
If someone does this, then they know what they are doing and realize that init
will harvest the child before they get the pid back and thus that the pid
should be ignored.
Note that neither fork() nor vfork() can end up in this case. Only a masochist
using rfork() and asking for this case will get it.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011218163100.jhb>