Subject: Re: random signals kill my processes with -current
To: Bill Studenmund <skippy@macro.STANFORD.EDU>
From: Chris G. Demetriou <cgd@CS.cmu.edu>
Date: 01/27/1997 19:54:57
> 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
(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
It's not a bad idea, but it's even harder to actually implement than
unmapped guard pages...