[peter at FreeBSD.org: cvs commit: src/sys/vm vm_map.c vm_map.h]

[Matthew Dillon]

    Good catch!  It does indeed apply to DFly too, though I have to do
    something slightly more sophisticated due to the upcall fields we store
    in the vmspace structure.

    Peter, the fork case is obvious, but what about the exec case in the
    face of rfork()'d threads?  I'm not entirely sure whether we should
    dup exitingcnt or not.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>

:FYI, Here is a FreeBSD RELENG_4 MFC which also applies to
:DragonFlyBSD, please review it, thanks!
:
:----- Forwarded message from Peter Wemm <peter at xxxxxxxxxxx> -----
:
:peter       2004/03/11 16:24:56 PST
:
:  FreeBSD src repository
:
:  Modified files:        (Branch: RELENG_4)
:    sys/vm               vm_map.c vm_map.h=20
:  Log:
:  MFC: part of vm_map.h rev 1.68 and vm_map.c 1.212.  This is actually
:  a prequisite of the vm_map.c rev 1.280 that dillon prematurely MFC'ed
:  on Jan 13th, 2003.  Without this change, the kernel leaks vmspaces
:  to varying degrees depending on the circumstances.  Specifically,
:  vm_exitingcnt was being copied from the parent to the child when it
:  might have been non-zero.  This caused the child's vm_exitingcnt to
:  never hit zero.  This was blowing up machines at work.
: =20
:  Revision    Changes    Path
:  1.187.2.24  +1 -1      src/sys/vm/vm_map.c
:  1.54.2.6    +2 -1      src/sys/vm/vm_map.h
:----- End forwarded message -----
:
:--=20
:Xin LI <delphij frontfree net>	http://www.delphij.net/