• M
    mm: protect against concurrent vma expansion · 4128997b
    Michel Lespinasse 提交于
    expand_stack() runs with a shared mmap_sem lock.  Because of this, there
    could be multiple concurrent stack expansions in the same mm, which may
    cause problems in the vma gap update code.
    
    I propose to solve this by taking the mm->page_table_lock around such vma
    expansions, in order to avoid the concurrency issue.  We only have to
    worry about concurrent expand_stack() calls here, since we hold a shared
    mmap_sem lock and all vma modificaitons other than expand_stack() are done
    under an exclusive mmap_sem lock.
    
    I previously tried to achieve the same effect by making sure all growable
    vmas in a given mm would share the same anon_vma, which we already lock
    here.  However this turned out to be difficult - all of the schemes I
    tried for refcounting the growable anon_vma and clearing turned out ugly.
    So, I'm now proposing only the minimal fix.
    
    The overhead of taking the page table lock during stack expansion is
    expected to be small: glibc doesn't use expandable stacks for the threads
    it creates, so having multiple growable stacks is actually uncommon and we
    don't expect the page table lock to get bounced between threads.
    Signed-off-by: NMichel Lespinasse <walken@google.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Rik van Riel <riel@redhat.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    4128997b
mmap.c 80.6 KB