• Rik van Riel's avatar
    mm: remove VM_LOCK_RMAP code · fc148a5f
    Rik van Riel authored
    When a VMA is in an inconsistent state during setup or teardown, the worst
    that can happen is that the rmap code will not be able to find the page.
    
    The mapping is in the process of being torn down (PTEs just got
    invalidated by munmap), or set up (no PTEs have been instantiated yet).
    
    It is also impossible for the rmap code to follow a pointer to an already
    freed VMA, because the rmap code holds the anon_vma->lock, which the VMA
    teardown code needs to take before the VMA is removed from the anon_vma
    chain.
    
    Hence, we should not need the VM_LOCK_RMAP locking at all.
    Signed-off-by: default avatarRik van Riel <riel@redhat.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    fc148a5f
mmap.c 66.8 KB