From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5E0EC433FE for ; Thu, 10 Feb 2022 16:28:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244185AbiBJQ2O (ORCPT ); Thu, 10 Feb 2022 11:28:14 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:42812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229519AbiBJQ2N (ORCPT ); Thu, 10 Feb 2022 11:28:13 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD1AB98 for ; Thu, 10 Feb 2022 08:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644510494; x=1676046494; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=DGhm09HzjY8rDyG0mR3sFd/viujCm4K2akDYcHlitZo=; b=M5/EZc67DX7To/SxDbew/htzeWOrR2CqiFBoWW9Jg63Ij8EnrHoZRSOW g1ePUP3GHtVoTLGENSfzqsrT7xbAXQywTxs1YfIgRfmCLfDp/I6drsGw8 fW53vFRMf8xqBu7ZGyFz+edjVEvPAUbIwn9faMPUNV89HNlH8H3hUu7su rdia/nE6AxR7LNvrW5UdufjUkEAwE61X81/lIUW8M1Ye8iWU8qwrU5JcD IAfVBwYf0BdVveESjXd/GUHMQJfQ/IIhbKkCqrudeSEomehIl0uiXDO4m GGzsgdgnpUXLiHGTKD5UFzDrZBOiVkD1An5Yz/84YK2UkUp6pZjwROAlq g==; X-IronPort-AV: E=McAfee;i="6200,9189,10254"; a="247115433" X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="247115433" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 08:27:56 -0800 X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="701747201" Received: from otcwcpicx3.sc.intel.com ([172.25.55.73]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 08:27:56 -0800 Date: Thu, 10 Feb 2022 08:27:50 -0800 From: Fenghua Yu To: Jacob Pan Cc: Thomas Gleixner , Dave Hansen , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Tony Luck , 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: <20220209191614.5a3b42d4@jacob-builder> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks. -Fenghua