On 19-Dec-01 John Baldwin wrote: >> 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.
Actually, it's a bit worse than that. The parent process will sleep on itself waiting to be woken up, but when the child exits, it will wake up init (p->p_pptr) not the waiting process, so if you do a rfork(..., RFNOWAIT | RFPPWAIT); then the parent process will hang and never return. Perhaps fork1() should return EINVAL if both flags are set. What with preemption for interrupts and what not, RFNOWAIT could potentially always return an invalid pid though I think if the child process exits and the proc is reused prior to the original parent being resumed. Not sure how you want to fix this. Even if you return the right pid, that pid could be reused by some other process potentially, so going to extra work to return the right pid in that case would still be returning an invalid pid since the child has exited and been harvested by init already. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
