From owner-freebsd-current Wed Feb 16 20:44:27 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 3334537B559 for ; Wed, 16 Feb 2000 20:44:25 -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 156E8132D6 for ; Wed, 16 Feb 2000 20:43:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA56389; Wed, 16 Feb 2000 20:44:22 -0800 (PST) (envelope-from dillon) Date: Wed, 16 Feb 2000 20:44:22 -0800 (PST) From: Matthew Dillon Message-Id: <200002170444.UAA56389@apollo.backplane.com> To: Jason Evans Cc: current@FreeBSD.ORG Subject: MAP_GUARDED patch (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> <200002162333.PAA54729@apollo.backplane.com> <20000216155222.G18774@sturm.canonware.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, Feb 16, 2000 at 03:33:58PM -0800, Matthew Dillon wrote: :> 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. : :I would really like to see this change happen, and will happily make the :necessary libc_r and linuxthreads changes to use the functionality, but :we're well into the code freeze right now, which IMO makes this more :appropriate for 4.1. : :Jason I agree that this is just a tad too complex to go into 4.0 ... the MAP_GUARDED implementation is trivial, I did it in a few lines of code, but we don't want to accidently break threads at this late date and we are in a freeze, so... we'll commit this stuff after the release. I've worked up a patch to add MAP_GUARDED, which I give a reference to below. However, there are some issues: * MAP_GUARDED cannot be combined with MAP_STACK. You have to manage the 'stack' resource yourself by calling getrlimit() and checking it, then using a normal anonymous mmap. * While you can use fixed addresses with MAP_GUARDED maps, if you use downward trending address the VM system can't coalesce the VM objects, so the vm_map_entry optimization will not occur. Here is how MAP_GUARDED works: mmap(NULL, len, prot, MAP_GUARDED|MAP_ANON, -1, 0); mmap(addr, len, prot, MAP_GUARDED|MAP_ANON|MAP_FIXED, -1, 0); The returned map will be 'len' bytes long. The first and last page of this map will be guarded and accessing it will result in a bus fault (you get a seg fault if you access totally unmapped space, you get a bus fault if you access a guard page). So the offsets 0-4095 and len-4096 to len-1 will be guarded. I believe that this can be used in the current threads library but you have to pay attention to a couple of things: * First, you have to use mmap(NULL... ), allocating out of the normal mmap space rather then allocating out of the user stack space. * Second, remember that both the first AND the last page of the returned map is guarded. * Third, since we are not allocating out of the user stack space, you must call getrlimit() and manage the stack resource limit yourself. You might as well do this anyway, because MAP_STACK currently allows you to mmap() out-of-range stacks but then faults when you try to access them. Broken!!! * Lastly, as with MAP_STACK, don't even try calling madvise() on a submap of any of these maps, nor use mmap() to submap any of these maps. Both MAP_STACK and MAP_GUARDED break badly if you do that (MAP_STACK might even potentially crash the machine, but I haven't checked it deeply yet). I believe that I can fix the downward-trending optimization problem but it's more work then I have time for right now. Please check out the patch and tell me what you think. http://www.backplane.com/FreeBSD4/ http://www.backplane.com/FreeBSD4/guard-1.diff http://www.backplane.com/FreeBSD4/guard.c I also looked at the linux threads library. They do guard pages in a way that is just as broken as the way we do them, but I'm not sure if there is a kernel resource issue for them. It looks like it would be easy to patch the port to be optimal under FreeBSD. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message