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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1FBF5C433EF for ; Tue, 26 Apr 2022 04:35:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C778F82C21; Tue, 26 Apr 2022 04:35:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agJFzDkpL3rP; Tue, 26 Apr 2022 04:35:48 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9221E828AA; Tue, 26 Apr 2022 04:35:47 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6458BC0039; Tue, 26 Apr 2022 04:35:47 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 15563C002D for ; Tue, 26 Apr 2022 04:35:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0B91C60F40 for ; Tue, 26 Apr 2022 04:35:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=intel.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8Pv9BW1l0Yu for ; Tue, 26 Apr 2022 04:35:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by smtp3.osuosl.org (Postfix) with ESMTPS id 0D93360E30 for ; Tue, 26 Apr 2022 04:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650947745; x=1682483745; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=HoSgYXIAQU+NGqckIO+BRiklpNR9Ayr8HUcEmJ0UHcE=; b=ZCjW20/+91lruoBrkbbVvNmOv4I2ihYK9cjh9fp1q96LnNAgr26s5Olz VTNsuVQZN1LxVNhdXNc3F8GorV3Lr4JmGI42P4utR/ZRof8I+NUqLi3dd UVu6csQF+Xn0yxGOP/QbzbGRqokHMe++LDB+bJEJZhv+GaQAmGQyxn3IC J3qenFIvMEEZ0PO8g4qNd7nzdCVT2al8/vaQE+FBz1ZbUu/w5J/aM92rS M7nMIa4JQQLCUeXgGhKJSEjHIoBzeb2EUmbWy4MudojU8YqM5qOpBGq8h +AxW8hil6DWAqdm2setb1r9jLwFkYtefB/fXF0nju9eW/htUCnAee0Sff g==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="265254109" X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="265254109" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 21:35:44 -0700 X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="595563703" Received: from fyu1.sc.intel.com ([172.25.103.126]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 21:35:43 -0700 Date: Mon, 25 Apr 2022 21:36:19 -0700 From: Fenghua Yu To: Zhangfei Gao 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: <76ec6342-0d7c-7c7b-c132-2892e4048fa1@intel.com> <20220425083444.00af5674@jacob-builder> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: Jean-Philippe Brucker , Ashok Raj , Ravi V Shankar , Peter Zijlstra , will@kernel.org, Dave Hansen , x86 , linux-kernel , Dave Hansen , iommu , Tony Luck , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner , robin.murphy@arm.com, Ingo Molnar X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" T24gVHVlLCBBcHIgMjYsIDIwMjIgYXQgMTI6Mjg6MDBQTSArMDgwMCwgWmhhbmdmZWkgR2FvIHdy b3RlOgo+IEhpLCBKZWFuCj4gCj4gT24gMjAyMi80LzI2IOS4iuWNiDEyOjEzLCBKZWFuLVBoaWxp cHBlIEJydWNrZXIgd3JvdGU6Cj4gPiBIaSBKYWNvYiwKPiA+IAo+ID4gT24gTW9uLCBBcHIgMjUs IDIwMjIgYXQgMDg6MzQ6NDRBTSAtMDcwMCwgSmFjb2IgUGFuIHdyb3RlOgo+ID4gPiBIaSBKZWFu LVBoaWxpcHBlLAo+ID4gPiAKPiA+ID4gT24gTW9uLCAyNSBBcHIgMjAyMiAxNToyNjo0MCArMDEw MCwgSmVhbi1QaGlsaXBwZSBCcnVja2VyCj4gPiA+IDxqZWFuLXBoaWxpcHBlQGxpbmFyby5vcmc+ IHdyb3RlOgo+ID4gPiAKPiA+ID4gPiBPbiBNb24sIEFwciAyNSwgMjAyMiBhdCAwNzoxODozNkFN IC0wNzAwLCBEYXZlIEhhbnNlbiB3cm90ZToKPiA+ID4gPiA+IE9uIDQvMjUvMjIgMDY6NTMsIEpl YW4tUGhpbGlwcGUgQnJ1Y2tlciB3cm90ZToKPiA+ID4gPiA+ID4gT24gU2F0LCBBcHIgMjMsIDIw MjIgYXQgMDc6MTM6MzlQTSArMDgwMCwgemhhbmdmZWkuZ2FvQGZveG1haWwuY29tCj4gPiA+ID4g PiA+IHdyb3RlOgo+ID4gPiA+ID4gPiA+ID4gPiBPbiA1LjE3Cj4gPiA+ID4gPiA+ID4gPiA+IGZv cHNfcmVsZWFzZSBpcyBjYWxsZWQgYXV0b21hdGljYWxseSwgYXMgd2VsbCBhcwo+ID4gPiA+ID4g PiA+ID4gPiBpb21tdV9zdmFfdW5iaW5kX2RldmljZS4gT24gNS4xOC1yYzEuCj4gPiA+ID4gPiA+ ID4gPiA+IGZvcHNfcmVsZWFzZSBpcyBub3QgY2FsbGVkLCBoYXZlIHRvIG1hbnVhbGx5IGNhbGwg Y2xvc2UoZmQpCj4gPiA+ID4gPiA+ID4gPiBSaWdodCB0aGF0J3Mgd2VpcmQKPiA+ID4gPiA+ID4g PiBMb29rcyBpdCBpcyBjYXVzZWQgYnkgdGhlIGZpeCBwYXRjaCwgdmlhIG1tZ2V0LCB3aGljaCBt YXkgYWRkCj4gPiA+ID4gPiA+ID4gcmVmY291bnQgb2YgZmQuCj4gPiA+ID4gPiA+IFllcyBpbmRp cmVjdGx5IEkgdGhpbms6IHdoZW4gdGhlIHByb2Nlc3MgbW1hcHMgdGhlIHF1ZXVlLAo+ID4gPiA+ ID4gPiBtbWFwX3JlZ2lvbigpIHRha2VzIGEgcmVmZXJlbmNlIHRvIHRoZSB1YWNjZSBmZC4gVGhh dCByZWZlcmVuY2UgaXMKPiA+ID4gPiA+ID4gcmVsZWFzZWQgZWl0aGVyIGJ5IGV4cGxpY2l0IGNs b3NlKCkgb3IgbXVubWFwKCksIG9yIGJ5IGV4aXRfbW1hcCgpCj4gPiA+ID4gPiA+ICh3aGljaCBp cyB0cmlnZ2VyZWQgYnkgbW1wdXQoKSkuIFNpbmNlIHRoZXJlIGlzIGFuIG1tLT5mZCBkZXBlbmRl bmN5LAo+ID4gPiA+ID4gPiB3ZSBjYW5ub3QgYWRkIGEgZmQtPm1tIGRlcGVuZGVuY3ksIHNvIG5v IG1tZ2V0KCkvbW1wdXQoKSBpbgo+ID4gPiA+ID4gPiBiaW5kKCkvdW5iaW5kKCkuCj4gPiA+ID4g PiA+IAo+ID4gPiA+ID4gPiBJIGd1ZXNzIHdlIHNob3VsZCBnbyBiYWNrIHRvIHJlZmNvdW50ZWQg UEFTSURzIGluc3RlYWQsIHRvIGF2b2lkCj4gPiA+ID4gPiA+IGZyZWVpbmcgdGhlbSB1bnRpbCB1 bmJpbmQoKS4KPiA+ID4gPiA+IFllYWgsIHRoaXMgaXMgYSBiaXQgZ25hcmx5IGZvciAtcmM0LiAg TGV0J3MganVzdCBtYWtlIHN1cmUgdGhlcmUncwo+ID4gPiA+ID4gbm90aGluZyBlbHNlIHNpbXBs ZSB3ZSBjYW4gZG8uCj4gPiA+ID4gPiAKPiA+ID4gPiA+IEhvdyBkb2VzIHRoZSBJT01NVSBoYXJk d2FyZSBrbm93IHRoYXQgYWxsIGFjdGl2aXR5IHRvIGEgZ2l2ZW4gUEFTSUQgaXMKPiA+ID4gPiA+ IGZpbmlzaGVkPyAgVGhhdCBhY3Rpdml0eSBzaG91bGQsIHRvZGF5LCBiZSBpbmRlcGVuZGVudCBv ZiBhbiBtbSBvciBhCj4gPiA+ID4gPiBmZCdzIGxpZmV0aW1lLgo+ID4gPiA+IEluIHRoZSBjYXNl IG9mIHVhY2NlLCBpdCdzIHRpZWQgdG8gdGhlIGZkIGxpZmV0aW1lOiBvcGVuaW5nIGFuIGFjY2Vs ZXJhdG9yCj4gPiA+ID4gcXVldWUgY2FsbHMgaW9tbXVfc3ZhX2JpbmRfZGV2aWNlKCksIHdoaWNo IHNldHMgdXAgdGhlIFBBU0lEIGNvbnRleHQgaW4KPiA+ID4gPiB0aGUgSU9NTVUuIENsb3Npbmcg dGhlIHF1ZXVlIGNhbGxzIGlvbW11X3N2YV91bmJpbmRfZGV2aWNlKCkgd2hpY2gKPiA+ID4gPiBk ZXN0cm95cyB0aGUgUEFTSUQgY29udGV4dCAoYWZ0ZXIgdGhlIGRldmljZSBkcml2ZXIgc3RvcHBl ZCBhbGwgRE1BIGZvcgo+ID4gPiA+IHRoaXMgUEFTSUQpLgo+ID4gPiA+IAo+ID4gPiBGb3IgVlQt ZCwgaXQgaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgZmxvdyBleGNlcHQgbWFuYWdlZCBieSB0aGUg aW5kaXZpZHVhbAo+ID4gPiBkcml2ZXJzIHN1Y2ggYXMgRFNBLgo+ID4gPiBJZiBmcmVlKCkgaGFw cGVucyBiZWZvcmUgdW5iaW5kKCksIHdlIGRlYWN0aXZhdGUgdGhlIFBBU0lEcyBhbmQgc3VwcHJl c3MKPiA+ID4gZmF1bHRzIGZyb20gdGhlIGRldmljZS4gV2hlbiB0aGUgdW5iaW5kIGZpbmFsbHkg Y29tZXMsIHdlIGZpbmFsaXplIHRoZQo+ID4gPiBQQVNJRCB0ZWFyZG93bi4gSXQgc2VlbXMgd2Ug aGF2ZSBhIG5lZWQgZm9yIGFuIGludGVybWVkaWF0ZSBzdGF0ZSB3aGVyZQo+ID4gPiBQQVNJRCBp cyAicGVuZGluZyBmcmVlIj8KPiA+IFllcyB3ZSBkbyBoYXZlIHRoYXQgc3RhdGUsIHRob3VnaCBJ J20gbm90IHN1cmUgd2UgbmVlZCB0byBtYWtlIGl0IGV4cGxpY2l0Cj4gPiBpbiB0aGUgaW9hc2lk IGFsbG9jYXRvci4KPiA+IAo+ID4gQ291bGQgd2UgbW92ZSBtbV9wYXNpZF9kcm9wKCkgdG8gX19t bWRyb3AoKSBpbnN0ZWFkIG9mIF9fbW1wdXQoKT8gIEZvciBBcm0KPiA+IHdlIGRvIG5lZWQgdG8g aG9sZCB0aGUgbW1fY291bnQgdW50aWwgdW5iaW5kKCksIGFuZCBtbWdyYWIoKS9tbWRyb3AoKSBp cwo+ID4gYWxzbyBwYXJ0IG9mIEx1J3MgcmV3b3JrIFsxXS4KPiAKPiBNb3ZlIG1tX3Bhc2lkX2Ry b3AgdG8gX19tbWRyb3AgbG9va3Mgd29ya2FibGUuCj4gCj4gVGhlIG5naW54IHdvcmtzIHNpbmNl IGlvYXNpZCBpcyBub3QgZnJlZWQgd2hlbiBtYXN0ZXIgZXhpdCB1bnRpbCBuZ2lueCBzdG9wLgo+ IAo+IFRoZSBpb2FzaWQgZG9lcyBub3QgZnJlZSBpbW1lZGlhdGVseSB3aGVuIGZvcHNfcmVsZWFz ZS0+dW5iaW5kIGZpbmlzaGVkLgo+IEluc3RlYWQsIF9fbW1kcm9wIGhhcHBlbnMgYSBiaXQgbGF6 eSzCoCB3aGljaCBoYXMgbm8gaXNzdWUgdGhvdWdoCj4gSSBwYXNzZWQgMTAwMDAgdGltZXMgZXhp dCB3aXRob3V0IHVuYmluZCB0ZXN0LCB0aGUgcGFzaWQgYWxsb2NhdGlvbiBpcyBvay4KPiAKPiBU aGFua3MKPiAKPiAKPiBkaWZmIC0tZ2l0IGEva2VybmVsL2ZvcmsuYyBiL2tlcm5lbC9mb3JrLmMK PiBpbmRleCA5Nzk2ODk3NTYwYWIuLjYwZjQxN2Y2OTM2NyAxMDA2NDQKPiAtLS0gYS9rZXJuZWwv Zm9yay5jCj4gKysrIGIva2VybmVsL2ZvcmsuYwo+IEBAIC03OTIsNiArNzkyLDggQEAgdm9pZCBf X21tZHJvcChzdHJ1Y3QgbW1fc3RydWN0ICptbSkKPiDCoMKgwqDCoMKgwqDCoCBtbXVfbm90aWZp ZXJfc3Vic2NyaXB0aW9uc19kZXN0cm95KG1tKTsKPiDCoMKgwqDCoMKgwqDCoCBjaGVja19tbSht bSk7Cj4gwqDCoMKgwqDCoMKgwqAgcHV0X3VzZXJfbnMobW0tPnVzZXJfbnMpOwo+ICvCoMKgwqDC oMKgwqAgbW1fcGFzaWRfZHJvcChtbSk7Cj4gwqDCoMKgwqDCoMKgwqAgZnJlZV9tbShtbSk7Cj4g wqB9Cj4gwqBFWFBPUlRfU1lNQk9MX0dQTChfX21tZHJvcCk7Cj4gQEAgLTExOTAsNyArMTE5Miw2 IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX21tcHV0KHN0cnVjdCBtbV9zdHJ1Y3QgKm1tKQo+IMKg wqDCoMKgwqDCoMKgIH0KPiDCoMKgwqDCoMKgwqDCoCBpZiAobW0tPmJpbmZtdCkKPiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbW9kdWxlX3B1dChtbS0+YmluZm10LT5tb2R1bGUpOwo+ IC3CoMKgwqDCoMKgwqAgbW1fcGFzaWRfZHJvcChtbSk7Cj4gwqDCoMKgwqDCoMKgwqAgbW1kcm9w KG1tKTsKPiDCoH0KClRoYW5rIHlvdSB2ZXJ5IG11Y2gsIFpoYW5nZmVpIQoKSSBqdXN0IG5vdyBz ZW50IG91dCBhbiBpZGVudGljYWwgcGF0Y2guIEl0IHdvcmtzIG9uIFg4NiBhcyB3ZWxsLgoKU28g c2VlbXMgdGhlIHBhdGNoIGlzIHRoZSByaWdodCBmaXguCgpFaXRoZXIgeW91IGNhbiBzZW5kIG91 dCB0aGUgcGF0Y2ggb3IgSSBhZGQgeW91ciBTaWduZWQtb2ZmLWJ5PyBFaXRoZXIgd2F5CmlzIE9L IGZvciBtZS4KClRoYW5rcy4KCi1GZW5naHVhCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmlvbW11IG1haWxpbmcgbGlzdAppb21tdUBsaXN0cy5saW51eC1m b3VuZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pb21tdQ== 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 F2CD3C433EF for ; Tue, 26 Apr 2022 04:36:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244156AbiDZEjP (ORCPT ); Tue, 26 Apr 2022 00:39:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244109AbiDZEjN (ORCPT ); Tue, 26 Apr 2022 00:39:13 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 990EA6B08A for ; Mon, 25 Apr 2022 21:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650947766; x=1682483766; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=HoSgYXIAQU+NGqckIO+BRiklpNR9Ayr8HUcEmJ0UHcE=; b=kiG/hpzgmN0jivIdOA+8rKuPdv/BUGBz4ygC662lxKSW6yJxliBHf3vM +sJOgoPJt5j3acAGBPfG4fQCsRk9GZzXZwVV8EiR0Q9Hj8hPGvJBunSz7 C6qqG9UFDiNnLqw3ArJM8E1zat/w05qyKgRByg/ugWcq+aB4PuUGtKmkd Mn4Z3slTCSlGSZzvw+3AoOY7wJZHqP+ithHb7DGY8gXkRdceKfzO8w9Tg gwyijJKggdSpI88f7dGqxsHud7iivWfPNu87g3aIqmfG1hjaxKAR55klz gw7D3nuVaA1B8DAcuUlB2sBLLoK7uQNstyo679LUVyUtG9vuVRpM4cslG g==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="290590897" X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="290590897" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 21:35:44 -0700 X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="595563703" Received: from fyu1.sc.intel.com ([172.25.103.126]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 21:35:43 -0700 Date: Mon, 25 Apr 2022 21:36:19 -0700 From: Fenghua Yu To: Zhangfei Gao Cc: Jean-Philippe Brucker , Jacob Pan , Dave Hansen , Tony Luck , Ashok Raj , Ravi V Shankar , Peter Zijlstra , robin.murphy@arm.com, Dave Hansen , x86 , linux-kernel , iommu , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner , will@kernel.org 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: <76ec6342-0d7c-7c7b-c132-2892e4048fa1@intel.com> <20220425083444.00af5674@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 26, 2022 at 12:28:00PM +0800, Zhangfei Gao wrote: > Hi, Jean > > On 2022/4/26 上午12:13, Jean-Philippe Brucker wrote: > > Hi Jacob, > > > > On Mon, Apr 25, 2022 at 08:34:44AM -0700, Jacob Pan wrote: > > > Hi Jean-Philippe, > > > > > > On Mon, 25 Apr 2022 15:26:40 +0100, Jean-Philippe Brucker > > > wrote: > > > > > > > On Mon, Apr 25, 2022 at 07:18:36AM -0700, Dave Hansen wrote: > > > > > On 4/25/22 06:53, Jean-Philippe Brucker wrote: > > > > > > On Sat, Apr 23, 2022 at 07:13:39PM +0800, zhangfei.gao@foxmail.com > > > > > > wrote: > > > > > > > > > On 5.17 > > > > > > > > > fops_release is called automatically, as well as > > > > > > > > > iommu_sva_unbind_device. On 5.18-rc1. > > > > > > > > > fops_release is not called, have to manually call close(fd) > > > > > > > > Right that's weird > > > > > > > Looks it is caused by the fix patch, via mmget, which may add > > > > > > > refcount of fd. > > > > > > Yes indirectly I think: when the process mmaps the queue, > > > > > > mmap_region() takes a reference to the uacce fd. That reference is > > > > > > released either by explicit close() or munmap(), or by exit_mmap() > > > > > > (which is triggered by mmput()). Since there is an mm->fd dependency, > > > > > > we cannot add a fd->mm dependency, so no mmget()/mmput() in > > > > > > bind()/unbind(). > > > > > > > > > > > > I guess we should go back to refcounted PASIDs instead, to avoid > > > > > > freeing them until unbind(). > > > > > Yeah, this is a bit gnarly for -rc4. Let's just make sure there's > > > > > nothing else simple we can do. > > > > > > > > > > How does the IOMMU hardware know that all activity to a given PASID is > > > > > finished? That activity should, today, be independent of an mm or a > > > > > fd's lifetime. > > > > In the case of uacce, it's tied to the fd lifetime: opening an accelerator > > > > queue calls iommu_sva_bind_device(), which sets up the PASID context in > > > > the IOMMU. Closing the queue calls iommu_sva_unbind_device() which > > > > destroys the PASID context (after the device driver stopped all DMA for > > > > this PASID). > > > > > > > For VT-d, it is essentially the same flow except managed by the individual > > > drivers such as DSA. > > > If free() happens before unbind(), we deactivate the PASIDs and suppress > > > faults from the device. When the unbind finally comes, we finalize the > > > PASID teardown. It seems we have a need for an intermediate state where > > > PASID is "pending free"? > > Yes we do have that state, though I'm not sure we need to make it explicit > > in the ioasid allocator. > > > > Could we move mm_pasid_drop() to __mmdrop() instead of __mmput()? For Arm > > we do need to hold the mm_count until unbind(), and mmgrab()/mmdrop() is > > also part of Lu's rework [1]. > > Move mm_pasid_drop to __mmdrop looks workable. > > The nginx works since ioasid is not freed when master exit until nginx stop. > > The ioasid does not free immediately when fops_release->unbind finished. > Instead, __mmdrop happens a bit lazy,  which has no issue though > I passed 10000 times exit without unbind test, the pasid allocation is ok. > > Thanks > > > diff --git a/kernel/fork.c b/kernel/fork.c > index 9796897560ab..60f417f69367 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -792,6 +792,8 @@ void __mmdrop(struct mm_struct *mm) >         mmu_notifier_subscriptions_destroy(mm); >         check_mm(mm); >         put_user_ns(mm->user_ns); > +       mm_pasid_drop(mm); >         free_mm(mm); >  } >  EXPORT_SYMBOL_GPL(__mmdrop); > @@ -1190,7 +1192,6 @@ static inline void __mmput(struct mm_struct *mm) >         } >         if (mm->binfmt) >                 module_put(mm->binfmt->module); > -       mm_pasid_drop(mm); >         mmdrop(mm); >  } Thank you very much, Zhangfei! I just now sent out an identical patch. It works on X86 as well. So seems the patch is the right fix. Either you can send out the patch or I add your Signed-off-by? Either way is OK for me. Thanks. -Fenghua