From owner-freebsd-current  Fri Feb 18 13:24:29 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 73E5237BAA7
	for <current@FreeBSD.ORG>; Fri, 18 Feb 2000 13:24:25 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA81098;
	Fri, 18 Feb 2000 13:24:23 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 18 Feb 2000 13:24:23 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200002182124.NAA81098@apollo.backplane.com>
To: Alan Cox <alc@cs.rice.edu>
Cc: current@FreeBSD.ORG
Subject: Re: tentitive complete patch for MAP_GUARDED available
References:  <20000218122554.A2978@nonpc.cs.rice.edu>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Ok, I just finished making the modifications, essentially 
    rewriting vm_map_growstack() and vm_map_stack().

	http://www.backplane.com/FreeBSD4/
	http://www.backplane.com/FreeBSD4/guard-3.diff
	http://www.backplane.com/FreeBSD4/guard3.c


    Here are the proposed semantics:

    * When you mmap() with MAP_STACK, the stack you map is 
      limited to the number of bytes specified in the mmap()
      AND ALSO limited by the process stack resource limit
      (on a per-mmap basis).

      That is, *EACH* MAP_STACK mmaping may utilize up to
      the process stack resource and no more, even if you
      mmap a larger area.

      This may be a little controversial but it's basically
      how the kernel allocates the default user stack -- it
      allocates the maximum kernel limit and assumes the
      stack will be limited by the stack resource.  I think
      it could be useful for debugging, too.

      (Also, with MAP_STACK, a fixed address and an anonymous
      mmap is implied, and the mmap() will fail if the 
      specified region already contains mappings).

    * When you mmap() with MAP_GUARDED, the offset field in
      the mmap() call specifies the number of guard pages
      at the beginning and end of the map.  If you specify 0,
      you don't get any guard pages (which is kinda useless).
      Normally getpagesize() bytes is specified.

      An anonymous mmap is implied.

    * 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).

						-Matt



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