From owner-freebsd-hackers Mon Sep 23 12:52:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA17592 for hackers-outgoing; Mon, 23 Sep 1996 12:52:18 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA17573 for ; Mon, 23 Sep 1996 12:52:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02652; Mon, 23 Sep 1996 12:50:56 -0700 From: Terry Lambert Message-Id: <199609231950.MAA02652@phaeton.artisoft.com> Subject: Re: thread stacks and protections (was Re: attribute/inode caching) To: lada@ws2301.gud.siemens.co.at (Hr.Ladavac) Date: Mon, 23 Sep 1996 12:50:56 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, freebsd-hackers@freebsd.org In-Reply-To: <199609230808.AA175676096@ws2301.gud.siemens.co.at> from "Hr.Ladavac" at Sep 23, 96 10:08:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > This implies a heavier-than-expected mapping overhead. > > > > Another alternative is a hybrid approach: You zone for some amount, > > and then after you exceed your zone for a given thread, you engage > > in pmap changes. This "punishes" threads with "excessive" stack > > use, while leaving other threads unadulterated. It's probably the > > correct approach, if the stack can be made arbitrarily large. > > I have a problem with thread stacks in separate VM spaces. This, namely, > means that an RPC call that doesn't leave the process space cannot be > fully optimized away because I can not use auto variables as my > result areas without an additional copy. Same applies to the [in] > arguments, as well. > > What I want to say is that one thread cannot pass another thread an > address to an object on its stack. > > This is probably worth considering during design. The hybrid approach resolves this problem handily, since each zone mapping can be placed in the address space of all threads: ie, you don't have mapping differences (effectively). In this case, it means an out of bound reference which should have gotten an invalid page might get another threads stack instead. It's really to be expected, actually, since that's what happens with stack preaalocation in the current POSIX implementation anyway. This is where having a large scatterd address space is handy. If my address space is 2^64, and my process image space is 2^22 (4M or so), I have a 1 out of 2^42 chance of getting a good page where I expected a fault (ie: page anonymity based protection). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.