Date: Mon, 23 Sep 1996 12:50:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: lada@ws2301.gud.siemens.co.at (Hr.Ladavac) Cc: terry@lambert.org, michaelh@cet.co.jp, freebsd-hackers@freebsd.org Subject: Re: thread stacks and protections (was Re: attribute/inode caching) Message-ID: <199609231950.MAA02652@phaeton.artisoft.com> In-Reply-To: <199609230808.AA175676096@ws2301.gud.siemens.co.at> from "Hr.Ladavac" at Sep 23, 96 10:08:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609231950.MAA02652>