Kernel thread stack usage

[Marcel Moolenaar]

On Nov 11, 2007, at 8:34 PM, Julian Elischer wrote:

> Marcel Moolenaar wrote:
>> It's the register stack that grows faster in general and
>> yes, they grow towards each other so they can eventually
>> run into each other.
>
> so one could write something that detects tha tyou are getting close,
> but it would have to be machine dependent..

Yes. A good place would be cpu_switch in this case, because
the processor flushes the dirty stacked registers onto the
register stack only when it "feels" like it or when instructed
to do so. In practice this means that while the stacks may
have run into each other based on the pointers, the memory
corruption (sec) often happens in cpu_switch where we force
the processor to flush the dirty stacked registers.

In other words: a thread is expected in the common case to
encounter the corruption until the next switch-in, but could
in case of excessive use of either or both stacks encounter
it on function boundaries (function calls and/or returns).

As a side-note: The implementation of kernel stack guard pages
is just as meaningless for ia64. As a first improvement, you
want guard pages both at the top and at the bottom and not just
at the bottom. Secondly, you want to be able to protect each
stack running into each other. However, putting a guard page
somewhere in the middle may not be the right thing, because
different threads may require different ratios...

-- 
Marcel Moolenaar
xcllnt at mac.com