"Chris G. Demetriou" writes:
> > Wouldn't it be superior to detect and prevent the stack overflow? This
> > could happen on other architectures at some point, and the overflow
> > might go past the user structure...
[...]
> To make kernel stack overflows detectable in this situation, you'd
> need to add an (unmapped) guard page at the end of the kernel stack,
> putting the U area into its own page (or into malloc()d memory, but
> that's bad because swapping it out then becomes a fair bit harder,
> though by no means impossible).  This has the consequence of wasting
> most of a page of memory (the page containing the U area), unless you
> go the malloc() route.

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.

I would feel much more comfortable if we had them -- this silent
overflow thing may be leading to all sorts of inexplicable problems
(and not just during autoconfig).

> It also means that, on most/many architectures, kernel stack overflows
> can't be handled reasonably.  Since as of the time of the overflow,
> there's no space left to push data on to the stack, on most
> architectures there's no place to put the stack frame that indicates
> that the stack grew into the guard page...  Some architectures will
> deal with this sanely (e.g. on the alpha, i get sent back to the
> firmware with a KSP INVALID fault 8-), but many e.g. m68k will appear
> to spontaneously reboot.

At least, though, we might learn that we need to expand the stack by a
page, or that we have a kernel bug wasting kernel stack. I prefer to
know than not knowing.

Perry