From owner-freebsd-current Wed Feb 16 15:34: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from builder.freebsd.org (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id 8406F37B568 for ; Wed, 16 Feb 2000 15:33:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by builder.freebsd.org (Postfix) with ESMTP id F30DE132DE for ; Wed, 16 Feb 2000 15:33:20 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA54729; Wed, 16 Feb 2000 15:33:58 -0800 (PST) (envelope-from dillon) Date: Wed, 16 Feb 2000 15:33:58 -0800 (PST) From: Matthew Dillon Message-Id: <200002162333.PAA54729@apollo.backplane.com> To: Jason Evans , current@FreeBSD.ORG Subject: Re: Heads up, vm.max_proc_mmap sysctl added References: <200002162118.NAA54097@apollo.backplane.com> <20000216141339.C18774@sturm.canonware.com> <20000216141622.E18774@sturm.canonware.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message