From owner-freebsd-current Fri Feb 18 14:19:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id E867E37BAD3 for ; Fri, 18 Feb 2000 14:19:51 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA18866; Fri, 18 Feb 2000 16:41:15 -0500 (EST) Date: Fri, 18 Feb 2000 16:41:15 -0500 (EST) From: Daniel Eischen Message-Id: <200002182141.QAA18866@pcnet1.pcnet.com> To: alc@cs.rice.edu, dillon@apollo.backplane.com Subject: Re: tentitive complete patch for MAP_GUARDED available Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * When you mmap() with MAP_GUARDED|MAP_STACK, you get > a guarded stack. The system will not create a > growable stack, though, it pre-reserves the space > (but, of course, does not allocate physical pages > for things you haven't touched). > > The new semantics use the offset field in the mmap to > indicate the number of guard pages at the beginning and > end of the map, in bytes, so the semantics of MAP_GUARDED > mmap's has been changed somewhat. You nominally have > to call it with an offset of getpagesize() to get the > 'single guard page at beginning and end' behavior. > > So, to make the threads library use this you mmap > MAP_STACK|MAP_GUARDED with an offset of getpagesize() > (or more). Currently, the threads library only creates one guard page at the top (or bottom depending on how you look at it) of each threads stack (for stacks of default size). Thread stacks are allocated in sequential zones, so they are always placed on top of the previous threads stack, and thus already have a guard page below the stack. Correct me if I'm wrong, but using MAP_STACK|MAP_GUARDED would allocate one additional guard page for each threads stack. DanE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message