Messages in this thread |  | | From | Keith Owens <> | Subject | Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8 | Date | Fri, 25 May 2001 16:53:47 +1000 |
| |
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.
- 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/
|  |