Date: Wed, 16 Feb 2000 15:33:58 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jason Evans <jasone@canonware.com>, current@FreeBSD.ORG Subject: Re: Heads up, vm.max_proc_mmap sysctl added Message-ID: <200002162333.PAA54729@apollo.backplane.com> References: <200002162118.NAA54097@apollo.backplane.com> <20000216141339.C18774@sturm.canonware.com> <20000216141622.E18774@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> > This deals with a mmap+fork bomb that can cause the kernel to
:> > eat all of KVM in vm_map_entry structures. The default limit
:> > should be set generously enough for people using the current
:> > FreeBSD threads incarnation (and isn't an issue w/ linux
:> > threads due to rfork resulting in scaling of the limit for the
:> > shared address space).
:> >
:> > Heads up in case a heavy threads programmer sees something I missed.
:>
:> Note that thread stack allocation in libc_r also uses mmap() (one region
:> per thread), so this applies there as well.
:
:Never mind. Matt stated this correctly, and I misread it.
:
:Jason
Heh heh. Yes, this is my one worry - the guard page between thread
stacks as well as the fact that MAP_STACK is used causes a vm_map_entry
to be allocated for each thread stack, which is seriously annoying but
there is nothing we can do about it at the moment.
It is possible to fix the problem. We can add a new mmap() flag which
we call MAP_GUARDED which would basically be an anonymous mmap() which
implements a special case in vm_fault. This pager is designed to always
return a failure for the first and last page. The size of the mmap()
determines where the guard pages are and would be stored as part of
the vm_map_entry (only for the MAP_GUARDED case).
Adjacent vm_map_entry structures with the same guard size would be
coalesced.
Thus any threaded program will still only require a single vm_map_entry
field yet still be completely flexible in regards to the guard pages.
Is anyone interested in me doing this for the 4.0 release? It would
help both our current threads model and the linux threads model a lot.
I can do it in a day and it should be trivial to test, the modifications
are actually quite minor.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002162333.PAA54729>