Hi,

swapping != paging

Preventing swapping just prevents a few pages from being written to the swap 
device.
( 2-4 pages on i386)

There is also no reserved swap space in NetBSD.

Bad things happen if you run out of resources - but I really don't see any 
special
problems caused by fork/vfork.

	Stephan

> 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
> > 
> > 
> 
>