Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1016377pxb; Fri, 15 Apr 2022 18:27:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyo5VHXej7Eom6jRABXyLoGTqhL6nuQ8BlRS7sXrjBSIjZi9k+fjV26EWoEMKl8wj64Z2GT X-Received: by 2002:a17:903:246:b0:153:87f0:a93e with SMTP id j6-20020a170903024600b0015387f0a93emr1643471plh.171.1650072445754; Fri, 15 Apr 2022 18:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650072445; cv=none; d=google.com; s=arc-20160816; b=Myn5YvP8tgUTiq90w3ILaHaIUPQLG1NU2Bppw6O9vluyXGspf+5T4DXK0yABhrCrXX P+6scBX9MJsVRRgiSz9fcMKKFvRMcx+HI/AqitPYmarvS+ZXzZf5PmPRxBcw6inIdIeb lHcBLIPnZyaoU9WUeZPgS92ErSNHGl2EqEdzKNPuy9EagelkbdtBbv3KYmLWraPKA7cq 2fTh7Ml7KOwQx6U1nMBJpZo5nd7RCvRA7ZIPjZw2IMDimRs8YWu0BlSSJtADhp+n8AjF HoqHdI4NczcZKWGWIJfDv1oguRm1Jnm7yqFur5ksBMcOIjiBvsVx/ptipMPw7ycsHPbT pe+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=EMl1R/cdTvRIsco407N55J58+ycVKGrl1P3hNCNzMBU=; b=bhOLa1TOp7wiOvbI1MbCo31mXMOxSKJWj6QKgD3GNw5dHCNJ8uS65eIOvdmPhi5d+v y7mNdU7gIFZhgXYAAxmH9yYJ5IGcN48J9ol/l1HlM/FPqZFb5C1E/URSiiLksUbkb34Z amvoRAmxQiDEUrWPrsohGpaP8M+mEFQRTwegsRta+ABH1UVBSnNZkBWAlZlJ4ZKQtcxF v5hQzkfCBM9rW3P9LEG9l+dFgK69tSccC3JQCK8ZscKTEy1sDjRngd4eeUzVuAz1c72A sTTSiVTkyyqPSzHKA1GutgHqQSwDLhBzequnFGBviUTh6ZmHIJDghlYkNaAhxifYn35g go0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TP5+rRXb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id u18-20020a63a912000000b00399f81e320esi3169700pge.620.2022.04.15.18.27.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:27:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TP5+rRXb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 200DB4EDCA; Fri, 15 Apr 2022 17:58:17 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352298AbiDOU7A (ORCPT + 99 others); Fri, 15 Apr 2022 16:59:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344975AbiDOU67 (ORCPT ); Fri, 15 Apr 2022 16:58:59 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 827B435A8C for ; Fri, 15 Apr 2022 13:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650056190; x=1681592190; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TEr+410Cz7xxJFaUMGK2Bokxa0fZlL+QKprnPgzdbCg=; b=TP5+rRXbqsmuFna9FBPMBSUWEkZDCLH4JaoNAreabyRps7WQ2JWCZdjt AW4+P85FXK5ntY4v3bweuCAunw/W4vBlz/O+hitfiox5VTHyJokrcAGi5 NzMEvp7uo9bQQGs429FCHt8pfa0nY//gZaQP6YA/4aqXp95UDPNJnn+bU SfjqnkIi6Lp6p4nHqfHaqxGWN9CDOQWv1uXLTOCi/8fPlmqm1Ol1JPjyW oy08ytkKz5B0dZxrDhy8UUPbhq+RbsWrcDlPNzwjLbzb/2IKz7fu4SklI z7LxyiZyOeL+toQrNtzoCu4p5CyBwODas9VaWbqs4rXrWmRIMi0n/NBfH g==; X-IronPort-AV: E=McAfee;i="6400,9594,10318"; a="349677781" X-IronPort-AV: E=Sophos;i="5.90,263,1643702400"; d="scan'208";a="349677781" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 13:56:30 -0700 X-IronPort-AV: E=Sophos;i="5.90,263,1643702400"; d="scan'208";a="528061240" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.198.157]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 13:56:29 -0700 Date: Fri, 15 Apr 2022 14:00:02 -0700 From: Jacob Pan To: "zhangfei.gao@foxmail.com" Cc: Fenghua Yu , Ravi V Shankar , Tony Luck , Ashok Raj , jean-philippe , Peter Zijlstra , Dave Hansen , x86 , linux-kernel , Dave Hansen , iommu , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit Message-ID: <20220415140002.7c12b0d2@jacob-builder> In-Reply-To: References: <99bcb9f5-4776-9c40-a776-cdecfa9e1010@foxmail.com> Organization: OTC X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 zhangfei.gao@foxmail.com, On Fri, 15 Apr 2022 19:52:03 +0800, "zhangfei.gao@foxmail.com" wrote: > >>> A PASID might be still used even though it is freed on mm exit. > >>> > >>> process A: > >>> sva_bind(); > >>> ioasid_alloc() = N; // Get PASID N for the mm > >>> fork(): // spawn process B > >>> exit(); > >>> ioasid_free(N); > >>> > >>> process B: > >>> device uses PASID N -> failure > >>> sva_unbind(); > >>> > >>> Dave Hansen suggests to take a refcount on the mm whenever binding the > >>> PASID to a device and drop the refcount on unbinding. The mm won't be > >>> dropped if the PASID is still bound to it. > >>> > >>> Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID > >>> allocation and free it on mm exit") > >>> Is process A's mm intended to be used by process B? Or you really should use PASID N on process B's mm? If the latter, it may work for a while until B changes mapping. It seems you are just extending the life of a defunct mm? Thanks, Jacob