From: Davidlohr Bueso <dave@stgolabs.net>
To: jgg@ziepe.ca, akpm@linux-foundation.org
Cc: dledford@redhat.com, jgg@mellanox.com, jack@suse.cz,
willy@infradead.org, ira.weiny@intel.com,
linux-rdma@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, dave@stgolabs.net,
Davidlohr Bueso <dbueso@suse.de>
Subject: [PATCH 6/6] drivers/IB,core: reduce scope of mmap_sem
Date: Wed, 6 Feb 2019 09:59:20 -0800 [thread overview]
Message-ID: <20190206175920.31082-7-dave@stgolabs.net> (raw)
In-Reply-To: <20190206175920.31082-1-dave@stgolabs.net>
ib_umem_get() uses gup_longterm() and relies on the lock to
stabilze the vma_list, so we cannot really get rid of mmap_sem
altogether, but now that the counter is atomic, we can get of
some complexity that mmap_sem brings with only pinned_vm.
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
drivers/infiniband/core/umem.c | 41 ++---------------------------------------
1 file changed, 2 insertions(+), 39 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 678abe1afcba..b69d3efa8712 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -165,15 +165,12 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, unsigned long addr,
lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
- down_write(&mm->mmap_sem);
- new_pinned = atomic64_read(&mm->pinned_vm) + npages;
+ new_pinned = atomic64_add_return(npages, &mm->pinned_vm);
if (new_pinned > lock_limit && !capable(CAP_IPC_LOCK)) {
- up_write(&mm->mmap_sem);
+ atomic64_sub(npages, &mm->pinned_vm);
ret = -ENOMEM;
goto out;
}
- atomic64_set(&mm->pinned_vm, new_pinned);
- up_write(&mm->mmap_sem);
cur_base = addr & PAGE_MASK;
@@ -233,9 +230,7 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, unsigned long addr,
umem_release:
__ib_umem_release(context->device, umem, 0);
vma:
- down_write(&mm->mmap_sem);
atomic64_sub(ib_umem_num_pages(umem), &mm->pinned_vm);
- up_write(&mm->mmap_sem);
out:
if (vma_list)
free_page((unsigned long) vma_list);
@@ -258,25 +253,12 @@ static void __ib_umem_release_tail(struct ib_umem *umem)
kfree(umem);
}
-static void ib_umem_release_defer(struct work_struct *work)
-{
- struct ib_umem *umem = container_of(work, struct ib_umem, work);
-
- down_write(&umem->owning_mm->mmap_sem);
- atomic64_sub(ib_umem_num_pages(umem), &umem->owning_mm->pinned_vm);
- up_write(&umem->owning_mm->mmap_sem);
-
- __ib_umem_release_tail(umem);
-}
-
/**
* ib_umem_release - release memory pinned with ib_umem_get
* @umem: umem struct to release
*/
void ib_umem_release(struct ib_umem *umem)
{
- struct ib_ucontext *context = umem->context;
-
if (umem->is_odp) {
ib_umem_odp_release(to_ib_umem_odp(umem));
__ib_umem_release_tail(umem);
@@ -285,26 +267,7 @@ void ib_umem_release(struct ib_umem *umem)
__ib_umem_release(umem->context->device, umem, 1);
- /*
- * We may be called with the mm's mmap_sem already held. This
- * can happen when a userspace munmap() is the call that drops
- * the last reference to our file and calls our release
- * method. If there are memory regions to destroy, we'll end
- * up here and not be able to take the mmap_sem. In that case
- * we defer the vm_locked accounting a workqueue.
- */
- if (context->closing) {
- if (!down_write_trylock(&umem->owning_mm->mmap_sem)) {
- INIT_WORK(&umem->work, ib_umem_release_defer);
- queue_work(ib_wq, &umem->work);
- return;
- }
- } else {
- down_write(&umem->owning_mm->mmap_sem);
- }
atomic64_sub(ib_umem_num_pages(umem), &umem->owning_mm->pinned_vm);
- up_write(&umem->owning_mm->mmap_sem);
-
__ib_umem_release_tail(umem);
}
EXPORT_SYMBOL(ib_umem_release);
--
2.16.4
next prev parent reply other threads:[~2019-02-06 17:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 17:59 [PATCH v3 0/6] mm: make pinned_vm atomic and simplify users Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 2/6] drivers/mic/scif: do not use mmap_sem Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 3/6] drivers/IB,qib: optimize mmap_sem usage Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 4/6] drivers/IB,hfi1: do not se mmap_sem Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 5/6] drivers/IB,usnic: reduce scope of mmap_sem Davidlohr Bueso
2019-02-06 17:59 ` Davidlohr Bueso [this message]
2019-02-07 1:31 ` [PATCH 7/6] Documentation/infiniband: update from locked to pinned_vm Davidlohr Bueso
2019-02-12 0:35 ` Weiny, Ira
2019-02-07 20:12 ` [PATCH v3 0/6] mm: make pinned_vm atomic and simplify users Jason Gunthorpe
-- strict thread matches above, loose matches on Subject: below --
2019-01-21 17:42 [PATCH v2 -next " Davidlohr Bueso
2019-01-21 17:42 ` [PATCH 6/6] drivers/IB,core: reduce scope of mmap_sem Davidlohr Bueso
2019-01-21 18:32 ` Jason Gunthorpe
2019-01-21 19:12 ` Davidlohr Bueso
2019-01-21 21:53 ` Christopher Lameter
2019-01-15 18:12 [PATCH -next 0/6] mm: make pinned_vm atomic and simplify users Davidlohr Bueso
2019-01-15 18:13 ` [PATCH 6/6] drivers/IB,core: reduce scope of mmap_sem Davidlohr Bueso
2019-01-15 20:30 ` Ira Weiny
2019-01-15 20:53 ` Jason Gunthorpe
2019-01-15 21:12 ` Matthew Wilcox
2019-01-15 21:17 ` Jason Gunthorpe
2019-01-16 16:00 ` Davidlohr Bueso
2019-01-16 17:02 ` Jason Gunthorpe
2019-01-16 17:06 ` Matthew Wilcox
2019-01-16 17:29 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190206175920.31082-7-dave@stgolabs.net \
--to=dave@stgolabs.net \
--cc=akpm@linux-foundation.org \
--cc=dbueso@suse.de \
--cc=dledford@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=jgg@mellanox.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.