Subject: Re: NetBSD multi-threaded?
To: None <tech-kern@netbsd.org>
From: Anders Magnusson <ragge@ludd.luth.se>
List: tech-kern
Date: 09/13/1994 18:42:26
> 
> > Date: Mon, 12 Sep 1994 23:22:01 -0400
> > From: "Chris G. Demetriou" <cgd@alpha.bostic.com>
> 
> > charles said:
> > > In Net/2 and later, the struct user is now stored in a per-process
> > > location, not a fixed location for all processes.
> > 
> > Actually...  In Net/2 and later, each process has its own 'struct
> > user' location, but (at least as far as i'm aware) when a process is
> > curproc, its user struct is doubly-mapped to a constant address as
> > well.  That's definitely true of all the ports that i'm aware of (but
> > then, i'm not familiar with the low-level details of them all).
> > 
> > The reason for this is rather interesting: when you fork, you've gotta
> > copy the kernel stack.  the kernel stack typically lives at the 'high
> > end' of the UPAGES, and the per-process struct user lives at the low
> > end.  It's really a pain to have to re-thread the stack, so, by
> > remapping the UPAGES at a fixed address for all processes, and only
> > using the kernel stack in that mapping, a lot of hassle is avoided...
> 
> 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).
[deleted...]
> 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.
> 
> Does anyone else care about guard pages?
> Is there a better way to implement them?
> 
In VAX port, I relocated kernel stack at first, (it was easiest) but
now I double-map it on top of user stack. (much cheaper) In this uarea
which I have mapped myself there is an "red zone" directly above user
struct. I thought it was easy way to implement stack protection.
/ragge