Use guard pages and KMC allocator for kstacks
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 28 Nov 2016 16:29:28 +0000 (11:29 -0500)
committerBarret Rhoden <brho@cs.berkeley.edu>
Tue, 29 Nov 2016 16:27:40 +0000 (11:27 -0500)
commit846a77c3264c8d1add1dcbb26792f8eeb38de0d4
treeb519484f58ee14fe65671640bb8f61a102872a9b
parent33b1dd1bbcd3f36385286ec098978a1c15223dc1
Use guard pages and KMC allocator for kstacks

The main benefit is the guard pages, which allows us to rule out one source
of crazy kernel bugs: running off the end of your stack.

This allocator imports from vaddr_arena, allocs memory for the stack, and
sets up the virtual mapping.  Since the slab / KMC allocator caches
objects, these allocs and mappings are maintained until the cache either
voluntarily frees the object or a reclaim function runs.

There are a few interesting tidbits with reclaim when the time comes
(kstacks will need to set up a reclaim CB on kpages, which is where the
real pressure comes from).

The runtime allocations will come from the per-cpu magazine layer, once the
magazine is filled.  Actually, this was also happening with direct kpages
allocations previously, so there's no real change here.  It's just nice to
know.

For those who are still paranoid, you can adjust the number of guard pages
at compile time.  =)

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/src/kthread.c