From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v3 hmm 02/11] mm/mmu_notifiers: do not speculatively allocate a mmu_notifier_mm Date: Thu, 8 Aug 2019 12:26:52 +0200 Message-ID: <20190808102652.GC648@lst.de> References: <20190806231548.25242-1-jgg@ziepe.ca> <20190806231548.25242-3-jgg@ziepe.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190806231548.25242-3-jgg-uk2M96/98Pc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Jason Gunthorpe Cc: Andrea Arcangeli , "David (ChunMing) Zhou" , Ralph Campbell , Dimitri Sivanich , Gavin Shan , Andrea Righi , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, John Hubbard , "Kuehling, Felix" , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Christian =?iso-8859-1?Q?K=F6nig?= , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, =?iso-8859-1?B?Suly9G1l?= Glisse , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Jason Gunthorpe , Alex Deucher , intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Christoph Hellwig List-Id: intel-gfx@lists.freedesktop.org On Tue, Aug 06, 2019 at 08:15:39PM -0300, Jason Gunthorpe wrote: > From: Jason Gunthorpe > > A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary") > made an attempt at doing this, but had to be reverted as calling > the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see > commit 35cfa2b0b491 ("mm/mmu_notifier: allocate mmu_notifier in advance"). > > However, we can avoid that problem by doing the allocation only under > the mmap_sem, which is already happening. > > Since all writers to mm->mmu_notifier_mm hold the write side of the > mmap_sem reading it under that sem is deterministic and we can use that to > decide if the allocation path is required, without speculation. > > The actual update to mmu_notifier_mm must still be done under the > mm_take_all_locks() to ensure read-side coherency. > > Signed-off-by: Jason Gunthorpe Looks good, Reviewed-by: Christoph Hellwig