Date: Fri, 18 Feb 2000 16:41:15 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: alc@cs.rice.edu, dillon@apollo.backplane.com Cc: current@FreeBSD.ORG Subject: Re: tentitive complete patch for MAP_GUARDED available Message-ID: <200002182141.QAA18866@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> * 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002182141.QAA18866>