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 4F62AC433EF for ; Fri, 15 Apr 2022 20:56:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352325AbiDOU7A (ORCPT ); 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 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