From owner-cvs-sys  Thu May  2 04:57:43 1996
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id EAA19328
          for cvs-sys-outgoing; Thu, 2 May 1996 04:57:43 -0700 (PDT)
Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA19290
          Thu, 2 May 1996 04:56:48 -0700 (PDT)
Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id TAA00890; Thu, 2 May 1996 19:56:37 +0800 (WST)
Message-Id: <199605021156.TAA00890@spinner.DIALix.COM>
To: Peter Wemm <peter@freefall.freebsd.org>
cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/kern kern_fork.c 
In-reply-to: Your message of "Thu, 02 May 1996 04:38:07 MST."
             <199605021138.EAA18666@freefall.freebsd.org> 
Date: Thu, 02 May 1996 19:56:37 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Modified:    sys/kern  kern_fork.c
>  This is a minimal change to fix the problem, it will probably be done
>  better by reordering p_vmspace to be in the startzero section, but it
>  becomes harder to validate then.

Now that I think about it more, this may still not be enough..  If
the fork1() is interrupted while inserting the process onto the
allproc list, and the VM system walks the severed allproc list during
kernel growth, or interrupts a little later when the proc has been
inserted but before it's initialised, that would be just as bad.

If the kernel traverses the allproc list during an interrupt (eg: network,
to allocate more clusters?) to grow the kernel, then all changes to
allproc may need to need to be spl protected..

-Peter