[ .. ]
#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. If the kernel stack ever became that
large one of two things would happen on the sun4c:
a) if the first out of range stack accessed happened with
traps off as described above, the machine would incur
a "watchdog reset" which essentially drops you into
the PROM monitor, at such a point you cannot return
to the kernel to sync disks or anything but you can
get dumps of all the cpu registers at the time of the
reset and disassemble the code it was executing
b) else if traps were on you'd get a kernel fault which
would try to save the register state with traps off
and you end up with situation 'a' anyways
It's a tough problem to solve satisfactorily.
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><