[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190121183218.GK25149@mellanox.com>
Date: Mon, 21 Jan 2019 18:32:26 +0000
From: Jason Gunthorpe <jgg@...lanox.com>
To: Davidlohr Bueso <dave@...olabs.net>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"dledford@...hat.com" <dledford@...hat.com>,
"jack@...e.de" <jack@...e.de>,
"ira.weiny@...el.com" <ira.weiny@...el.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH 6/6] drivers/IB,core: reduce scope of mmap_sem
On Mon, Jan 21, 2019 at 09:42:20AM -0800, Davidlohr Bueso wrote:
> 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@...el.com>
> Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
> ---
> drivers/infiniband/core/umem.c | 41 ++---------------------------------------
> 1 file changed, 2 insertions(+), 39 deletions(-)
I think this addresses my comment..
Considering that it is almost all infiniband, I'd rather it go it go
through the RDMA tree with an ack from mm people? Please advise..
Thanks,
Jason
Powered by blists - more mailing lists