Date: Wed, 16 Feb 2000 11:06:34 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: sheldonh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/16573: extensive fork()+mmap() causes 4.0 kernel to panic() Message-ID: <200002161906.LAA53213@apollo.backplane.com> References: <200002160844.AAA58622@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Synopsis: extensive fork()+mmap() causes 4.0 kernel to panic()
:
:Responsible-Changed-From-To: freebsd-bugs->dillon
:Responsible-Changed-By: sheldonh
:Responsible-Changed-When: Wed Feb 16 00:43:53 PST 2000
:Responsible-Changed-Why:
:Matt, is the panic in vm_map_insert() expected behaviour inside an
:mmapping fork-bomb?
The kernel does not limit the number of mappings any given process can
make and when you combine that with fork() it's fairly easy to run
the kernel out of resources. Your test program ran the kernel out of
vm_entry structures. vm_map_insert() is just assuming that its allocation
will succeed when, in fact, NULL can be returned. Unfortunately at this
point returning an error would not help - with the system totally run
out of vm_map_entry structures it's effectively dead.
We should be able to fix this with a per-process sysctl limit on the
number of entries allowed in a vm_map structure. When combined with
a reasonable maxproc limit for users (like 40) it ought to protect
against this situation. I'll ask Jordan if I can make that change prior
to release but if not we can definitely fix it after release.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002161906.LAA53213>
