Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Keith Owens <kaos@ocs.com.au>]

On Fri, 25 May 2001 00:33:56 -0600 (MDT), 
Andreas Dilger <adilger@turbolinux.com> wrote:
>Keith Owens writes:
>> You cannot recover from a kernel stack overflow even with kdb.  The
>> exception handler and kdb use the stack that just overflowed.
>
>If it at least tells you that the stack has overflowed, and a backtrace
>of the stack up to that point, that would at least be useful for fixing
>the functions which caused the problem.

A small overflow of the kernel stack overwrites the struct task at the
bottom of the stack, recovery is dubious at best because we rely on
data in struct task.  A large overflow of the kernel stack either
corrupts the storage below this task's stack, which could hit anything,
or it gets a stack fault.

If we take a stack fault on ix86, stack_segment() is invoked.  Just
taking the fault and calling the routine uses the kernel stack which
has already overflowed, causing a double fault.  The double fault
handler uses the kernel stack, generating a triple fault.  The machine
is now dead.

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.