Re: Kernel stack corruption with SCSI

Ingo Molnar (
Sat, 4 Jan 1997 13:37:50 +0100 (MET)

On Fri, 3 Jan 1997, David S. Miller wrote:

> Date: Fri, 3 Jan 1997 19:21:05 +0100 (MET)
> From: Ingo Molnar <>
> [ .. ]
> #define alloc_kernel_stack() vmalloc(4096)
> #define free_kernel_stack(page) vfree((page))
> [ ... ]
> thus all kernel stacks are MMU protected and separated by a zero pte? I
> havent checked this (yet), just wondering wether someone has done this
> already. This is a bit safer (and the resulting fault is much more
> informative).
> (As someone already mentioned this suggested scheme would triple fault
> and require some new trap glue to recover from completely)
> We effectively do the above on the older sun4c Sparcs. This was out
> of necessity because the stack must be locked down in the TLB because
> trap entry code which runs with traps disabled must never fault when
> accessing the kernel stack, yet they must get at it in this state to
> save away the cpu registers before enabling traps again.
> So I set aside a portion of the kernel virtual address space to map
> task_struct's and kernel stacks, I put these into distinct 4 page
> chunks. And therefore I make sure the page right below the bottom of
> the kernel stack is not mapped. [...]

ok, i've coded this up for the i386 platform, and there are some (generic)
problems left. Fortunately the i386 trap glue logic stuff fits nicely into
the current i386 hardware task switching system, the 'double fault event'
is equivalent to 'switch_to(current,fault_handler_kernel_thread)'. Whee.
Now the problem:

i got problems tho when using kernel virtual memory as stack space: the
AHA2940 driver hangs in the init phase. Without having looked into the
SCSI code i bet the problem is that the driver allocates some (small)
control structure on the stack, and uses virt_to_bus(stackaddr) to set up
DMA, which looses badly with vmalloc()-ed memory.

is this problem present (and solved :) in the Sun4c trap logic? Or is this
an SCSI driver problem. (are drivers allowed to use stack memory as DMA

If the driver behaviour is ok, then i guess the correct solution is to
give back the 'kernel linear address' from alloc_kernel_stack(), and
revert this in 'free_kernel_stack'. Generic MMU address translation is not
inversible (in a simple way), so i guess the best solution is to use some
special area for the kernel stack (and avoid vmalloc()), which address is
easily inversible in free_kernel_stack()?

but maybe the hang is due to something else ... :) still debugging it.

-- mingo