[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180205012754.23615-23-dbueso@wotan.suse.de>
Date: Mon, 5 Feb 2018 02:27:12 +0100
From: Davidlohr Bueso <dbueso@...e.de>
To: akpm@...ux-foundation.org, mingo@...nel.org
Cc: peterz@...radead.org, ldufour@...ux.vnet.ibm.com, jack@...e.cz,
mhocko@...nel.org, kirill.shutemov@...ux.intel.com,
mawilcox@...rosoft.com, mgorman@...hsingularity.net,
dave@...olabs.net, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>
Subject: [PATCH 22/64] mm: avoid mmap_sem trylock in vm_insert_page()
From: Davidlohr Bueso <dave@...olabs.net>
The rules to this function state that mmap_sem must
be acquired by the caller:
- for write if used in f_op->mmap() (by far the most common case)
- for read if used from vma_op->fault()(with VM_MIXEDMAP)
The only exception is:
mmap_vmcore()
remap_vmalloc_range_partial()
mmap_vmcore()
But there is no concurrency here, thus mmap_sem is not held.
After auditing the kernel, the following drivers use the fault
path and correctly set VM_MIXEDMAP):
.fault = etnaviv_gem_fault
.fault = udl_gem_fault
tegra_bo_fault()
As such, drop the reader trylock BUG_ON() for the common case.
This avoids having file_operations know about mmranges, as
mmap_sem is held during, mmap() for example.
Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
---
mm/memory.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index 5adcdc7dee80..7c69674cd9da 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1773,7 +1773,6 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned long addr,
if (!page_count(page))
return -EINVAL;
if (!(vma->vm_flags & VM_MIXEDMAP)) {
- BUG_ON(down_read_trylock(&vma->vm_mm->mmap_sem));
BUG_ON(vma->vm_flags & VM_PFNMAP);
vma->vm_flags |= VM_MIXEDMAP;
}
--
2.13.6
Powered by blists - more mailing lists