From owner-freebsd-current  Fri Feb 18 14: 9: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 4F24D37BA9E
	for <current@FreeBSD.ORG>; Fri, 18 Feb 2000 14:09:04 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id OAA81369;
	Fri, 18 Feb 2000 14:09:02 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 18 Feb 2000 14:09:02 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200002182209.OAA81369@apollo.backplane.com>
To: Daniel Eischen <eischen@vigrid.com>
Cc: alc@cs.rice.edu, current@FreeBSD.ORG
Subject: Re: tentitive complete patch for MAP_GUARDED available
References:  <200002182141.QAA18866@pcnet1.pcnet.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

: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.

    Correct.  At the moment MAP_GUARDED is a 'generic' guarding flag
    and makes no assumptions about the areas being adjoining.  It doesn't
    cost us anything.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message