This is an interesting analysis and I don't know enough here to do other
than pass it on for others (Chuck, Jason?) to comment on...

Forwarded message:
> From owner-misc+M50465@openbsd.org Sun Feb  1 05:21:01 2004
> Date: Sat, 31 Jan 2004 13:14:57 -0500 (EST)
> From: Siddhartha Annapureddy <siddhart@cs.nyu.edu>
> To: Artur Grabowski <art@blahonga.org>
> cc: misc@openbsd.org
> Subject: sys/kern/kern_fork.c potential deadlock
> In-Reply-To: <87oeskw4is.fsf@tratt.blahonga.org>
> Message-ID: <Pine.GSO.4.56.0401311257520.20745@slinky.cs.nyu.edu>
> References: <Pine.GSO.4.56.0401301653310.1207@slinky.cs.nyu.edu> <87oeskw4is.fsf@tratt.blahonga.org>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-Loop: misc@openbsd.org
> Precedence: list
> Sender: owner-misc@openbsd.org
> Content-Length: 2048
> 
> Hi Artur and others,
>           I noticed in the 4.4 BSD kernel book that the parent process is
> locked against swapping to avoid deadlock. And then the following sentence
> refers to the child being in an inconsistent state and hence we need the
> parent to complete the copying of user stack etc. So, I am not sure it's
> just paranoia.
> 	One potential deadlock scenario is this :
> The parent tries to get its stack into memory to copy to the child and in
> the effort, takes a page fault and then gets swapped out. Then other
> processes take over and claim the full amount of virtual address space
> they reserved apriori. If the memory and the swap are both filled at this
> point, the system is going to deadlock. But if the parent were to be in
> main memory (to be precise its user area), then it can continue its
> copying of the child and then release some memory potentially as the
> parent would have had reserved swap space (hopefully). But this
> seems like a rare scenario. Any comments and help are appreciated. Thanks.
> Bye.
> 
> A.Siddhartha.
> 
> On Sat, 31 Jan 2004, Artur Grabowski wrote:
> 
> > Siddhartha Annapureddy <siddhart@cs.nyu.edu> writes:
> >
> > > Hi all,
> > >      there seems to be a phold call for the parent process in fork1
> > > function in the kern_fork.c file. Could someone tell me why the parent
> > > process needs to be locked from getting swapped out. Are there some
> > > potential deadlocks if we don't pin it in memory? Thanks for the help.
> >
> > I think it's added paranoia that doesn't cost much.
> >
> > PHOLD makes sure that the kernel stack of the process doesn't get
> > swapped out.  Since in every place where we fiddle with the stack of
> > the parent process we are actually running the parent process, it
> > shouldn't matter. Of course, it doesn't cost much either. It might be
> > a method to make sure that in case the parent process blocks for some
> > reason (most likely allocating memory), we don't have to wait for
> > ages for the fork to finish.
> >
> > So the answer is: it's probably not necessary, but there is no reason
> > to change it.
> >
> > //art
> 
>