From owner-freebsd-current Tue Dec 18 16:31:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id D7AD037B416 for ; Tue, 18 Dec 2001 16:31:14 -0800 (PST) Received: (qmail 31509 invoked from network); 19 Dec 2001 00:31:14 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Dec 2001 00:31:14 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 18 Dec 2001 16:31:00 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: RE: Is this a bug in the fork() code? Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 <>< 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