Subject: Re: sys/kern/kern_fork.c potential deadlock (fwd)
To: Darren Reed <email@example.com>
From: Stephan Uphoff <firstname.lastname@example.org>
Date: 01/31/2004 17:06:06
swapping != paging
Preventing swapping just prevents a few pages from being written to the swap
( 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
problems caused by fork/vfork.
> 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 <email@example.com>
> > To: Artur Grabowski <firstname.lastname@example.org>
> > cc: email@example.com
> > Subject: sys/kern/kern_fork.c potential deadlock
> > In-Reply-To: <firstname.lastname@example.org>
> > Message-ID: <Pine.GSO.email@example.com>
> > References: <Pine.GSO.firstname.lastname@example.org> <email@example.com>
> > MIME-Version: 1.0
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> > X-Loop: firstname.lastname@example.org
> > Precedence: list
> > Sender: email@example.com
> > 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 <firstname.lastname@example.org> 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