From: Jason Gunthorpe <jgg@ziepe.ca>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: akpm@linux-foundation.org, dledford@redhat.com, jack@suse.de,
ira.weiny@intel.com, linux-rdma@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
dennis.dalessandro@intel.com, mike.marciniszyn@intel.com,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 3/6] drivers/IB,qib: do not use mmap_sem
Date: Mon, 28 Jan 2019 21:46:07 -0700 [thread overview]
Message-ID: <20190129044607.GL25106@ziepe.ca> (raw)
In-Reply-To: <20190128233140.GA12530@ziepe.ca>
On Mon, Jan 28, 2019 at 04:31:40PM -0700, Jason Gunthorpe wrote:
> On Mon, Jan 21, 2019 at 09:42:17AM -0800, Davidlohr Bueso wrote:
> > The driver uses mmap_sem for both pinned_vm accounting and
> > get_user_pages(). By using gup_fast() and letting the mm handle
> > the lock if needed, we can no longer rely on the semaphore and
> > simplify the whole thing as the pinning is decoupled from the lock.
> >
> > This also fixes a bug that __qib_get_user_pages was not taking into
> > account the current value of pinned_vm.
> >
> > Cc: dennis.dalessandro@intel.com
> > Cc: mike.marciniszyn@intel.com
> > Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> > drivers/infiniband/hw/qib/qib_user_pages.c | 67 ++++++++++--------------------
> > 1 file changed, 22 insertions(+), 45 deletions(-)
>
> I need you to respin this patch/series against the latest rdma tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
>
> branch for-next
>
> > diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c
> > -static int __qib_get_user_pages(unsigned long start_page, size_t num_pages,
> > - struct page **p)
> > -{
> > - unsigned long lock_limit;
> > - size_t got;
> > - int ret;
> > -
> > - lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> > -
> > - if (num_pages > lock_limit && !capable(CAP_IPC_LOCK)) {
> > - ret = -ENOMEM;
> > - goto bail;
> > - }
> > -
> > - for (got = 0; got < num_pages; got += ret) {
> > - ret = get_user_pages(start_page + got * PAGE_SIZE,
> > - num_pages - got,
> > - FOLL_WRITE | FOLL_FORCE,
> > - p + got, NULL);
>
> As this has been rightly changed to get_user_pages_longterm, and I
> think the right answer to solve the conflict is to discard some of
> this patch?
.. and I'm looking at some of the other conversions here.. *most
likely* any caller that is manipulating rlimit for get_user_pages
should really be calling get_user_pages_longterm, so they should not
be converted to use _fast?
Jason
next prev parent reply other threads:[~2019-01-29 4:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 17:42 [PATCH v2 -next 0/6] mm: make pinned_vm atomic and simplify users Davidlohr Bueso
2019-01-21 17:42 ` [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter Davidlohr Bueso
2019-01-21 21:51 ` Christopher Lameter
2019-01-22 9:56 ` Jan Kara
2019-01-22 15:45 ` Daniel Jordan
2019-01-23 18:33 ` Jason Gunthorpe
2019-01-28 21:10 ` Andrew Morton
2019-01-21 17:42 ` [PATCH 2/6] mic/scif: do not use mmap_sem Davidlohr Bueso
2019-01-21 17:42 ` [PATCH 3/6] drivers/IB,qib: " Davidlohr Bueso
2019-01-28 23:31 ` Jason Gunthorpe
2019-01-29 4:46 ` Jason Gunthorpe [this message]
2019-01-29 14:14 ` Davidlohr Bueso
2019-01-29 18:50 ` Ira Weiny
2019-01-29 23:19 ` Jason Gunthorpe
2019-01-30 18:01 ` Weiny, Ira
2019-01-31 10:04 ` Jan Kara
2019-01-21 17:42 ` [PATCH 4/6] drivers/IB,hfi1: do not se mmap_sem Davidlohr Bueso
2019-01-21 17:42 ` [PATCH 5/6] drivers/IB,usnic: reduce scope of mmap_sem Davidlohr Bueso
2019-01-21 17:42 ` [PATCH 6/6] drivers/IB,core: " Davidlohr Bueso
2019-01-21 18:32 ` Jason Gunthorpe
2019-01-21 19:12 ` Davidlohr Bueso
2019-01-21 21:53 ` Christopher Lameter
-- strict thread matches above, loose matches on Subject: below --
2019-01-15 18:12 [PATCH -next 0/6] mm: make pinned_vm atomic and simplify users Davidlohr Bueso
2019-01-15 18:12 ` [PATCH 3/6] drivers/IB,qib: do not use mmap_sem Davidlohr Bueso
2019-01-15 20:29 ` Ira Weiny
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=20190129044607.GL25106@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=dennis.dalessandro@intel.com \
--cc=dledford@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jack@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mike.marciniszyn@intel.com \
/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.