lkml.org 
[lkml]   [2012]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH -V6 05/14] hugetlb: Avoid taking i_mmap_mutex in unmap_single_vma for hugetlb
    Date
    From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>

    i_mmap_mutex lock was added in unmap_single_vma by 502717f4e112b18d9c37753a32f675bec9f2838b
    But we don't use page->lru in unmap_hugepage_range any more. Also the lock was
    taken higher up in the stack in some code path. That would result in deadlock.

    unmap_mapping_range (i_mmap_mutex)
    -> unmap_mapping_range_tree
    -> unmap_mapping_range_vma
    -> zap_page_range_single
    -> unmap_single_vma
    -> unmap_hugepage_range (i_mmap_mutex)

    For shared pagetable support for huge pages, since pagetable pages are
    ref counted we don't need any lock during huge_pmd_unshare. We do take
    i_mmap_mutex in huge_pmd_share while walking the vma_prio_tree in mapping.
    ( 39dde65c9940c97fcd178a3d2b1c57ed8b7b68aa )

    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    ---
    mm/memory.c | 5 +----
    1 file changed, 1 insertion(+), 4 deletions(-)

    diff --git a/mm/memory.c b/mm/memory.c
    index 4b11961..d642b3e 100644
    --- a/mm/memory.c
    +++ b/mm/memory.c
    @@ -1326,11 +1326,8 @@ static void unmap_single_vma(struct mmu_gather *tlb,
    * Since no pte has actually been setup, it is
    * safe to do nothing in this case.
    */
    - if (vma->vm_file) {
    - mutex_lock(&vma->vm_file->f_mapping->i_mmap_mutex);
    + if (vma->vm_file)
    __unmap_hugepage_range(tlb, vma, start, end, NULL);
    - mutex_unlock(&vma->vm_file->f_mapping->i_mmap_mutex);
    - }
    } else
    unmap_page_range(tlb, vma, start, end, details);
    }
    --
    1.7.10


    \
     
     \ /
      Last update: 2012-04-16 12:47    [W:0.019 / U:90.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site