On Fri, 25 May 2001 10:20:15 +0200,
Andi Kleen <ak@suse.de> wrote:
>On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote:
>> The only way to avoid those problems is to move struct task out of the
>> kernel stack pages and to use a task gate for the stack fault and
>> double fault handlers, instead of a trap gate (all ix86 specific).
>> Those methods are expensive, at a minimum they require an extra page
>> for every process plus an extra stack per cpu. I have not even
>> considered the extra cost of using task gates for the interrupts nor
>> how this method would complicate methods for getting the current struct
>> task pointer. It is not worth the bother, we write better kernel code
>> than that.
>
>When you don't try to handle recursive stack/double faults it only requires
>a single static stack per CPU. With some tricks and minor races it is also
>possible to handle multiple ones.
That is exactly what I said above, a separate fault task with its own
stack for every cpu. But there is no point in doing this to detect a
hardware stack overflow when the overflow has already corrupted the
struct task which is at the bottom of the stack segment.
To get any benefit from hardware detection of kernel stack overflow you
must also dedicate the stack segment to hold only stack data. That
means moving struct task to yet another page, adding an extra page per
task. It is just too expensive, we write better code than that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:22 EST