> I'm assuming that we know where, for each process, the kernel stack is
> supposed to end, and that it's not suposed to change during the life of a
> process (but might be different for different processies; I don't know).
> 
> [ ... ]
>
> Its not a perfect idea, but it might work, and certainly could give us
> warnings we don't presently have, and should be platform independant.

So, this has some advantages: most notably, you can detect that you
have overflowed your stack, and panic in a 'sane' way.

However, it also has some disadvantages:

(1) you can't tell exactly _when_ you overflowed your stack.

(2) you waste an extra page of RAM per process.  (You don't
    necessarily have to do this, but if you don't you might not
    even be able to tell what _process_ was running when the stack
    overflowed.)

(3) you can't easily switch between 'debugging' (i.e. waste the page)
    and non-debugging (don't waste the page) versions, because, at
    least at one point i believe that there were things in user-land
    that wanted to look into the kstack of dead processes.  (that may
    not be true now, indeed may never have been.  but if it is, you
    can't change the size arbitrarily.)

Note also that any implementation which seeks to avoid wasting a full
page for every process (and remember, these are wired pages, which can
be _swapped_ out, but can't just be paged out) _can't_ be platform
independent because it's going to have to play some ugly mapping
games.


It's not a bad idea, but it's even harder to actually implement than
unmapped guard pages...


chris