> From: gwr@jericho.mc.com (Gordon W. Ross)
> Date: Tue, 13 Sep 94 11:07:52 EDT
> To: cgd@alpha.bostic.com
> Cc: michaelv@headcandy.com, tech-kern@NetBSD.ORG
> Subject: NetBSD multi-threaded? 
> 
> ...
> On a related note, I was looking into implementing a "guard page"
> for the kernel stack, and realized I can not easily do it with the
> current layout of UPAGES.  For a guard page, I would like to have
> the kernel stack at the beginning of the UPAGES and the struct user
> at the end (at least on a machine where stacks grow downward).
> This way, kernel stack overflow touches an invalid page instead of
> trashing the user struct.  Currently, fork "knows" this layout...
> 
On the 68k (hp300), UPAGES was originally 3 with the idea that a guard
page would be placed between the kernel stack and the user struct.
However, there is a problem on the 68k.  If you make the guard page
no-access (or even read-only) you take an exception and the first thing
the processor does is push an exception frame on the currently active
supervisor stack which is now no-access or write-protected and you wind
up halting the CPU.  As far as I know, you always have to have a valid
supervisor SP.

Another thing to consider is that a kernel routine could allocate a
local data structure whose size is greater than 1 page and you could wind
up stepping right over the guard page and trashing something anyway.

> As a portability issue, struct upages should be defined in the
> architecture-specific code to allow a weird, stack-grows-up-
> machine to reverse teh order of the members of struct upages.
> One could even add stuff, like the current struct pcb, or some
> floating-point state, etc. to struct upages if desired.
> 
The other solution is to seperate the k-stack for the user struct.
I think the only reason they are together is so that they can be swapped
in one chunk.

BTW: the PA-RISC has an upward-growing stack, one of a number of
interesting features that break "portable" O.S.es like Mach.