On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
> vmalloc_node.
[...]
> static struct thread_info *alloc_thread_info_node(struct task_struct *tsk,
> int node)
> {
> +#ifdef CONFIG_VMAP_STACK
> + struct thread_info *ti = __vmalloc_node_range(
> + THREAD_SIZE, THREAD_SIZE, VMALLOC_START, VMALLOC_END,
> + THREADINFO_GFP | __GFP_HIGHMEM, PAGE_KERNEL,
> + 0, node, __builtin_return_address(0));
> +
After spender gave some hints on IRC about the guard pages not working
reliably, I decided to have a closer look at this. As far as I can
tell, the idea is that __vmalloc_node_range() automatically adds guard
pages unless the VM_NO_GUARD flag is specified. However, those guard
pages are *behind* allocations, not in front of them, while a stack
guard primarily needs to be in front of the allocation. This wouldn't
matter if all allocations in the vmalloc area had guard pages behind
them, but if someone first does some data allocation with VM_NO_GUARD
and then a stack allocation directly behind that, there won't be a
guard between the data allocation and the stack allocation.
(I might be wrong though; this is only from looking at the code, not
from testing it.)
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
