Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3033949pxb; Thu, 10 Feb 2022 10:40:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJzsxVay5R1CeI1lihRrxGZyLORpgULvYXuQCrwNVW/1f+kUS2CXziahrcmKjLRvSU5sjkdT X-Received: by 2002:aa7:cb8c:: with SMTP id r12mr9735402edt.164.1644518405622; Thu, 10 Feb 2022 10:40:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644518405; cv=none; d=google.com; s=arc-20160816; b=ixDNBq2rjTAKzhQp1voyZqTQq+oOQHo4NPp/seC0ndcoKRIOhSQAa13jQrlYrnbIJh 9FJ4lczBSJechIXlA+Rj5sUYWkgReayBva/3zhAXgZtqQv2H4x5ZbbXBQFqCwisPa1n+ 2V0Z6OvN8HMOwqmKmojmmTbw80YGcogL483kho9KYTc05yfAFtXxet6rBcVyzMyMXq70 0tRY3Ii5fur2hwp0mIi6rZTeYfwppl/5e1BgDEM9xGD955qW4AafaMFX+8Wy10W40AMe IIUAeB58FgtpjhUPS/XR0xyfqiFC2y0BZgrwRi2wCqfq+VECTZQa/p6itqJnwdMkS6Gs zahg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YgtufHqFAkrJq8yKmvpDpT9o1djtGouB5CLyndAcjWg=; b=Yal6VN1s85Q+Ta905j3/5BNLK/DmmPEZMN0hS02xCgvTJY2BKKSAiEznFrkzE19bmq 3VzgWa8CMHKdF6j2TwL3ftNOeZRIKzWTu5FMliBZSfuh878t086jngjhG9xMIXdSrELj F8+gWBVkXyTz0TrIwpZrlCKh6BVgIpCYRVQa+5JMcJpr5t7435G2kqXdny3x5YVjJ+3U 78M+NF/8xwrJ+/a+Va8IThDJzxEbvRENaL4g519hjgfPVsls7bdgJG4Rp51EbmYAhcJb JAeCAYkbElk9WBgr1sI2rVYzlISPKShio7UhHg1ca1sxAzGOHXKyPCyyQQw/FL4row7N qi8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WUgdN8FA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dd2si5131731ejc.334.2022.02.10.10.39.38; Thu, 10 Feb 2022 10:40:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WUgdN8FA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245736AbiBJSbm (ORCPT + 99 others); Thu, 10 Feb 2022 13:31:42 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:56816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245186AbiBJSbk (ORCPT ); Thu, 10 Feb 2022 13:31:40 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA77ECED for ; Thu, 10 Feb 2022 10:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644517901; x=1676053901; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=FlFaC+FPw/XthIPB5ReSE0a0cEsKH2AB9QD90on8UY8=; b=WUgdN8FA2NKBCBXHomhptsAkp7w1+YBCCsvpghvdE88tfKNU0vu8iKgi jKxi/I1UpHvEo5h5pCyHVSC1M8cjkSyJRdue6IX/fyHIQ3OFbC2nJVnpC fCKdcAlaMD2kcHSQoEF3CIjqcTHD9I2a84wCzCSNhR5XpgmpXQvMJaOwy inxtTEKiK07+WXiFFYP8gO7AGXH9699ItOrw9U2HLVASujJ7fefI12e9Z Lxmb6KpRH8D54NdxbGw5Xjq3p0z2YE4VZoiKYHjrqDOBo6bXM+ApL8mN/ BGU/dDkkzN1nVfsMp6gJvQ8v1TvjZmSvBA3yOOK17OhokJjKhHmmtUq3u Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10254"; a="312844647" X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="312844647" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 10:31:40 -0800 X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="541737864" Received: from otcwcpicx3.sc.intel.com ([172.25.55.73]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 10:31:40 -0800 Date: Thu, 10 Feb 2022 10:31:35 -0800 From: Fenghua Yu To: "Luck, Tony" Cc: Jacob Pan , Thomas Gleixner , Dave Hansen , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Lu Baolu , Joerg Roedel , Josh Poimboeuf , Ashok Raj , Ravi V Shankar , iommu@lists.linux-foundation.org, x86 , linux-kernel Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit Message-ID: References: <20220207230254.3342514-1-fenghua.yu@intel.com> <20220207230254.3342514-6-fenghua.yu@intel.com> <20220209191614.5a3b42d4@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Tony, On Thu, Feb 10, 2022 at 09:24:50AM -0800, Luck, Tony wrote: > On Thu, Feb 10, 2022 at 08:27:50AM -0800, Fenghua Yu wrote: > > Hi, Jacob, > > > > On Wed, Feb 09, 2022 at 07:16:14PM -0800, Jacob Pan wrote: > > > Hi Fenghua, > > > > > > On Mon, 7 Feb 2022 15:02:48 -0800, Fenghua Yu wrote: > > > > > > > @@ -1047,8 +1040,6 @@ struct iommu_sva *intel_svm_bind(struct device > > > > *dev, struct mm_struct *mm, void } > > > > > > > > sva = intel_svm_bind_mm(iommu, dev, mm, flags); > > > > - if (IS_ERR_OR_NULL(sva)) > > > > - intel_svm_free_pasid(mm); > > > If bind fails, the PASID has no IOMMU nor CPU context. It should be safe to > > > free here. > > > > The PASID can not be freed even if bind fails. The PASID allocated earlier > > (either in this thread or in another thread) might be populated to other > > threads already and being used now. > > > > Without freeing the PASID on bind failure, the worst case is the PASID might > > not be used in the process (and will be freed on process exit anyway). > > > > This all matches with the PASID life time described in the commit message. > > But what does this mean for the user that failed that intel_svm_bind_mm()? > That means the user may have a PASID but there is no PASID entry for the device. Then ENQCMD cannot be executed successfully. > Here's a scenario: > > Process sets up to use PASID capable device #1. Everything works, > so the process has mm->pasid, and the IOMMU has the tables to map > virtual addresses coming from device #1 using that PASID. > > Now the same process asks to start using PASID capable device #2, > but there is a failure at intel_svm_bind_mm(). > > Fenghua is right that we shouldn't free the PASID. It is in use > by at least one thread of the process to access device #1. > > But what happens with device #2? Does the caller of intel_svm_bind() > do the right thing with the IS_ERR_OR_NULL return value to let the > user know that device #2 isn't accessible? A driver caller of intel_svm_bind() should handle this failure, i.e. fail the binding and let the user know the failure. Even if the driver doesn't do the right thing to handle the failure, intel_svm_bind() doesn't set up a PASID entry for device #2. One example is IDXD driver. User calls open()->IDXD driver idxd_cdev_open() ->intel_svm_bind()->intel_svm_bind_mm(). idxd_cdev_open() gets failed "sva" and passes the PTR_ERR(sva) to the user and the user cannot open the device. Due to the failure, no PASID entry is set up for the device. Even if the user ignores the open() failure and tries to run ENQCMD on device #2, a PASID table fault will be generated due to no PASID entry for the device and the ENQCMD execution will fail. Thanks. -Fenghua