Instead of having to check the (entire?) page for the reserved value, why
not just check the current kstack pointer to see if it's within 1 page of
the real bottom?  In other words, allocate the extra page, but barf if we
ever find out we actually got that close...

On Mon, 27 Jan 1997, Bill Studenmund wrote:

> On Mon, 27 Jan 1997, Perry E. Metzger wrote:
> 
> > 
> > Jason Thorpe writes:
> > > On Mon, 27 Jan 1997 16:49:21 -0500 
> > >  "Perry E. Metzger" <perry@piermont.com> wrote:
> > > 
> > >  > The 4.4 book claimed that most 4.4. ports already had a guard page at
> > >  > the end of the kernel stack -- I was unaware that this was not the
> > >  > case any longer.
> > > 
> > > So, the hp300 port had this long ago... it was a bit easier to do
> > > in 4.4BSD because of the double-mapping of the kernel stack.  I.e.
> > > the "guard page" address never changed, because the kernel stack
> > > for all processes was mapped to the same address (kstack) upon
> > > context switch.
> > > 
> > > When kstack went away, the stack checking stuff was garbage-collected.
> > 
> > This sounds, though, like its something that might be worth bringing
> > back if it can be done. For all we know, lots of weird bugs would
> > suddenly be found.
> 
> Perhaps I'm missing something, but would this idea (I'm about to suggest)
> work? I'll freely admit I don't greatly understand this part of the
> kernel, yet ;-)
> 
> 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).
> 
> What if we taked a real guard page to the end of the stack. It would be 4k
> or 8k (whatever is the minimum), and we would fill it with some knowm
> value. Or if there's data stored below the stack, it's just a buffer zone.
> We fill it with a data value which we don't expect to be bassed to a
> subroutine, like a word-unaligned address for an unmapped area. When ever
> we context switch (or at other times like some stage of autoconfig), we
> check to see that the values we stored are still there. If no, something
> went wrong, and we note it.
> 
> This idea is different from a guard page in that we don't get a
> screetching halt when we overflow, but would work on processors that would
> freak if they didn't have a stack (ones that lack fall-back stacks).
> Hopefully the overflow is small, so that the buffer protects whatever's
> below it. And hopefully we don't overflow with code which gives the exact
> flag value as a subroutine parameter.
> 
> 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.
> 
> Take care,
> 
> Bill
> 
> 
>