lkml.org 
[lkml]   [2016]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 06/13] fork: Add generic vmalloced stack support
    On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski <luto@kernel.org> 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.)

    \
     
     \ /
      Last update: 2016-06-21 12:41    [W:7.455 / U:2.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site