From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751222AbcGWGdT (ORCPT ); Sat, 23 Jul 2016 02:33:19 -0400 Received: from mail-pa0-f67.google.com ([209.85.220.67]:35501 "EHLO mail-pa0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750774AbcGWGdP (ORCPT ); Sat, 23 Jul 2016 02:33:15 -0400 Date: Sat, 23 Jul 2016 16:33:07 +1000 From: Nicholas Piggin To: Alexey Kardashevskiy Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alex Williamson , Paul Mackerras , David Gibson Subject: Re: [kernel,v2,1/2] powerpc/iommu: Stop using @current in mm_iommu_xxx Message-ID: <20160723163307.628999ce@roar.ozlabs.ibm.com> In-Reply-To: <1468989271-753-2-git-send-email-aik@ozlabs.ru> References: <1468989271-753-2-git-send-email-aik@ozlabs.ru> Organization: IBM X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jul 2016 14:34:30 +1000 Alexey Kardashevskiy wrote: > static long tce_iommu_register_pages(struct tce_container *container, > @@ -128,10 +129,17 @@ static long tce_iommu_register_pages(struct > tce_container *container, ((vaddr + size) < vaddr)) > return -EINVAL; > > - ret = mm_iommu_get(vaddr, entries, &mem); > + if (!container->mm) { > + if (!current->mm) > + return -ESRCH; /* process exited */ This shouldn't happen if we're a userspace process. > + > + atomic_inc(¤t->mm->mm_count); > + container->mm = current->mm; > + } > + > + ret = mm_iommu_get(container->mm, vaddr, entries, &mem); Is it possible for processes (different mm) to be using the same container? > @@ -354,6 +362,8 @@ static void tce_iommu_release(void *iommu_data) > tce_iommu_free_table(tbl); > } > > + if (container->mm) > + mmdrop(container->mm); > tce_iommu_disable(container); > mutex_destroy(&container->lock); I'm wondering why keep the mm around at all. There is a bit of locked_vm accounting there (which maybe doesn't exactly do the right thing if we're talking about current task's rlimit if the mm does not belong to current anyway). The interesting cases are only the ones where a thread does something with container->mm when current->mm != container->mm (either a different process or a kernel thread). In what situations does that happen? Thanks, Nick