[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190121191202.xygjopuuifyepd63@linux-r8p5>
Date: Mon, 21 Jan 2019 11:12:02 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: Jason Gunthorpe <jgg@...lanox.com>
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>, willy@...radead.org
Subject: Re: [PATCH 6/6] drivers/IB,core: reduce scope of mmap_sem
On Mon, 21 Jan 2019, Jason Gunthorpe wrote:
>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..
Yeah also Cc'ing Willy who I forgot to add for v2.
>
>Thanks,
>Jason
Powered by blists - more mailing lists