From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754717AbcGVOAg (ORCPT ); Fri, 22 Jul 2016 10:00:36 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:61001 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754301AbcGVOAe (ORCPT ); Fri, 22 Jul 2016 10:00:34 -0400 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: npiggin@ozlabs.au.ibm.com X-IBM-RcptTo: kvm@vger.kernel.org;linux-kernel@vger.kernel.org Date: Sat, 23 Jul 2016 00:00:24 +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 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 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16072214-0012-0000-0000-000001AE6E4B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16072214-0013-0000-0000-000005A08B6F Message-Id: <20160723000024.65562d86@roar.ozlabs.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-22_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=48 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607220160 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?