From owner-freebsd-current Fri Feb 18 19: 3:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 5F57737BB49 for ; Fri, 18 Feb 2000 19:03:42 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 31068 invoked by uid 1001); 19 Feb 2000 03:02:56 -0000 Date: Fri, 18 Feb 2000 19:02:56 -0800 From: Jason Evans To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: tentitive complete patch for MAP_GUARDED available Message-ID: <20000218190256.E28177@sturm.canonware.com> References: <20000218122554.A2978@nonpc.cs.rice.edu> <200002181905.LAA80267@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200002181905.LAA80267@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Feb 18, 2000 at 11:05:31AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 18, 2000 at 11:05:31AM -0800, Matthew Dillon wrote: > I also think that a single guard page at the base of the > stack may be insufficient for some applications. I'm > considering adding yet another field to vm_map_entry > 'vm_pindex_t guard_pages' which allows the number of > guard pages to be specified (we can use mmap()'s offset > argument to pass the parameter). In general, a given number of guard pages is insufficient for some (perhaps non-existent) applications. The basic idea is to catch typical stack overflow. Trying to always catch stack overflow is not practical. Since this is a heuristic error detection technique, I'm not sure how much work/complexity it's worth to paramaterize the number of guard pages for each mapping. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message