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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8E06C001DE for ; Sat, 29 Jul 2023 00:47:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 219316B0071; Fri, 28 Jul 2023 20:47:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C9A36B0072; Fri, 28 Jul 2023 20:47:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01B798D0001; Fri, 28 Jul 2023 20:47:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E09E06B0071 for ; Fri, 28 Jul 2023 20:47:14 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 989601601CB for ; Sat, 29 Jul 2023 00:47:14 +0000 (UTC) X-FDA: 81062810388.02.DEBB823 Received: from mgamail.intel.com (unknown [192.55.52.93]) by imf22.hostedemail.com (Postfix) with ESMTP id E9054C000E for ; Sat, 29 Jul 2023 00:47:09 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kvghHTDF; dmarc=pass (policy=none) header.from=intel.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf22.hostedemail.com: domain of vivek.kasireddy@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690591631; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=V9klvFuPAxNGejQJx1ZbRMxWf8q+9UTmSfOujCYHU4M=; b=JHHTuvpv3zMsdFvgA4A+CsngcNVKcwP5U0lvAeBG/Ub+GSFDaquXHzxFTZqPEa7IfOS6uR H9zadVEZoUJ1zko5rwzY+yHRlIrtrYFxdxOVihjovx3ktDCRqskgDd/CnDUaN5Qyo/X8qU dDPEPezk6hkxFqb1s1NULrGXVX1g2FA= ARC-Authentication-Results: i=2; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kvghHTDF; dmarc=pass (policy=none) header.from=intel.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf22.hostedemail.com: domain of vivek.kasireddy@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1690591631; a=rsa-sha256; cv=pass; b=O1gDv5+t5FIWi+LEPdnldZ456DLtI4kae9h/nLaj1HSzrwJ2j/2naJr4EqDNPQlYnYNLAQ ycXjkA5h5SQHbDo/UW27uPMKensPoav4juQgwjJ9OkP+UxlY/aGmk3LDuul5++9+ETzjkP UxzV+tZhMlWeXN76y/gG/eO0y6kD2e8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690591630; x=1722127630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9izxBFcfH2ck+AzJrLF2V7IqFyft59gkFsc71gccqK4=; b=kvghHTDFxgVEqnY6Kd6s0sTi+mAAIJeTcwXKn6n/Teep0hNWpi05YSbx 6xPRrUqtoCA43JFWSlb+da4awszb21MUJEHl8d9m3LpTaRomxRdSH117k 9vLE/bRW6iESHhoZ0PRr8/1bgzlR5qvwQ6iPre7+EKw06jcUHGCl5I0B9 EQ9ZE9dlpvqNinCfR3PigrGb9G/OM0RkK778b3gWlhd3+1XHHxCuo+gdj mLPQ+k/SUAMTv0uGgquB78aqKqeQBbHnCgUASwhYmCJFc93DAWoxtFDPB s27kjc30t1FaDF7nTvx17fqGttVkHkjtCCkByAUTzlFO0NuN1TT/4niLc A==; X-IronPort-AV: E=McAfee;i="6600,9927,10785"; a="366181854" X-IronPort-AV: E=Sophos;i="6.01,238,1684825200"; d="scan'208";a="366181854" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2023 17:47:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10785"; a="974257306" X-IronPort-AV: E=Sophos;i="6.01,238,1684825200"; d="scan'208";a="974257306" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga006.fm.intel.com with ESMTP; 28 Jul 2023 17:47:07 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 28 Jul 2023 17:47:07 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 28 Jul 2023 17:47:06 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27 via Frontend Transport; Fri, 28 Jul 2023 17:47:06 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.174) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.27; Fri, 28 Jul 2023 17:47:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KCvzrjbIykSXilIRUfMh6Baa2COy1N4D/JFA77Bnip1QdMMWCro6XASdsFnAxb7uWoTuXOC/kILa7W3PacBZBdPDT8kNw7yzmL9eqd0w84Wm9RTyLi1iRNUqePxlZzmMp7fThVhkWst2muVYKhMqWgu6x2cSoJHfh1Zdcuvn2CkRpaHGkIn91sBIdI1SfGOly7kUG+yPZ1k53uDI2cE4VH91ScHx6ekazNotCEWWAuTpojSU+bwgz53Y90Hz+Q4JCF52gXuoaegSqTAzvzGY02Fbf299ubOBFqXdXcta2hV7FGuzOELfKlQMaAOcIGjzmyEP7A3Zhl3oehTgeJnqcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V9klvFuPAxNGejQJx1ZbRMxWf8q+9UTmSfOujCYHU4M=; b=J1Ai2c07bOsgM+JzHaomlo/NrFErXak19KGLDo9uMRTp6OltYKgZzWSSRtPlSEy5JhlPYsyHo7frYf95tYYfGHqL+kwVzk6JifvmN7n6i6OlAM7znsTp7bxrBMaoNSc87Dw9K3g8kjK/W1xZF5bvwHzaFjNiDprVZS1TY/UQFVPdb4KTV4lqPx0+UQKnyWkhfEK7LRzTKWtc1QCtpS7iL+BNninifmypn47yQJzB/le0FOrytf6Emo0IHbNhzLb9wEgSx/m8VDG47/V3CvkCNitJbPvlR7PCj1G0eBZ3u/6UP1MEqXXZVO+vGcyr7DXtCVfOPlKbfTnLNrIL25jghg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from CH3PR11MB7177.namprd11.prod.outlook.com (2603:10b6:610:153::8) by SA0PR11MB4559.namprd11.prod.outlook.com (2603:10b6:806:9a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6631.29; Sat, 29 Jul 2023 00:46:59 +0000 Received: from CH3PR11MB7177.namprd11.prod.outlook.com ([fe80::9cba:c1de:ea9f:fba7]) by CH3PR11MB7177.namprd11.prod.outlook.com ([fe80::9cba:c1de:ea9f:fba7%5]) with mapi id 15.20.6631.026; Sat, 29 Jul 2023 00:46:59 +0000 From: "Kasireddy, Vivek" To: Jason Gunthorpe CC: Alistair Popple , Gerd Hoffmann , "Kim, Dongwon" , David Hildenbrand , "Chang, Junxiao" , Hugh Dickins , Peter Xu , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , "Mike Kravetz" Subject: RE: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages) Thread-Topic: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages) Thread-Index: AQHZuVToVshy99YkkE2dGyNcPWpnjq/AWUSAgAGkBBCAAGFsAIAF9M/ggAChIwCAADi24IABSWKAgABl6ECAAEZHgIABcLAQgAD86oCAAQfUEA== Date: Sat, 29 Jul 2023 00:46:59 +0000 Message-ID: References: <87jzuwlkae.fsf@nvdebian.thelocal> <87pm4nj6s5.fsf@nvdebian.thelocal> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH3PR11MB7177:EE_|SA0PR11MB4559:EE_ x-ms-office365-filtering-correlation-id: a236617a-9f3c-48e2-64ab-08db8fcd5127 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vRKAvAyt/etf1nhnvUCmWEwjCY6nsEdpwo/suMsq637VqfIHBlrD1zJE1ZqN/NLc/NYKi7GsYt8k5FOS1Akr6pzUJ/RSyN040bhFMACCRQ344oYvKPFJ1nUZnh4ulxM3jcwOFordfV/dR5plIY6JU0pjolYjk/g2+U2yRtxqLru3scb3gd4X3RbiqXFePbBe8zCB9wYIPo/EsMrYKPoRqQb0rMCWHMQgV60WAX6cTyvGMVXKevRA/QduBfEbRoxd9YwYaGE2ojYnf6q7R43c4Me3/Iwh4zF3o+k+t+asp61vrEy3MLJXPxapnD/s/yrVW9pVzn4/eAu1UqjZ3HFJvjjBWDtd4XWbQDGalxOoxKS1TsqZS5xs2gz98hVLbQwWK1efqg4pOKfAKa5P+N1xDw13jzS/0ttNCTVaWiWpsP1I9qIwf7aHX4iN/P24hHco4qaPVmh2jrP97wC4c/L0/d6LEMkl2gZEY5BWn5+do+/AIjw40kg9KTdwV7VwhJELYmE9m/R3U0y4fPHyIrKHOMI1VZjJacpa3ReCXnkdUWie1APbXNdCx9ik0Dve9ds5WqQOWKWCUnosvzRUH4U+hC02FM9LIRo4gkCf4UqtRWZ56RYoaNM/3KvOQySBiMtD x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR11MB7177.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(396003)(136003)(376002)(346002)(39860400002)(366004)(451199021)(26005)(82960400001)(6506007)(9686003)(54906003)(186003)(71200400001)(478600001)(122000001)(7696005)(64756008)(66476007)(66446008)(4326008)(6916009)(83380400001)(38100700002)(66556008)(66946007)(76116006)(5660300002)(41300700001)(52536014)(33656002)(15650500001)(38070700005)(316002)(8936002)(2906002)(86362001)(8676002)(66899021)(55016003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?njiEnmAuCBUYdk/L4bde0VqCnO/kx8nqamXDbLgpjNL3FNAFtZwuBBE3Fm0h?= =?us-ascii?Q?p2YoNnAM7t5cjCou46r8rXiyM1G92jrQclBn0r1jch75INhVXGa0cdLQ38ql?= =?us-ascii?Q?DkIDumfL8TMOV23ocSpW3VusT3ZsnXF4l+PKHKYDvW7KUlIkZ3ULEZ8/iSmh?= =?us-ascii?Q?iZch1sE/hq7fU8mFxm5QRWFXUbRrcoxdibjYjlLl+X4u9T2Q+LOd3M48R5Xg?= =?us-ascii?Q?WIRftj5V7rCDhHyP9NSmerBPhWJ4CBWJ82U5O7zF61FhM55NZgZL25Pp2cud?= =?us-ascii?Q?bw5hvhG/gHCn90PO0XwxWWrCZWiKQ8oSvi/YgB3tZJVG0zhcHP4eLb+XTEXd?= =?us-ascii?Q?tlc42LHZYe2+EYDznnniTunxXeoNmMQQFLignY2jcfZ3rX5HgeFKV1EJFbKq?= =?us-ascii?Q?QJIiruMUAC2SeanbBrifuyleE4ahg8Hqs+naY55TDO6m2GkbAvT8i/gou3zY?= =?us-ascii?Q?CxwcYXBeY25oQGwLi6NP7aV/ml2ZaUi634eJ410IcfjKMEqZKZPv14cznHUU?= =?us-ascii?Q?0FrT6X1HAlA97qJ7H7PKRdvJ8sX1dk+d459+dYCTvlIYugLbfSUF1NEbTDDM?= =?us-ascii?Q?Yfc2aD7VOaYyd/xNFXURzWn1wTkPhFZ5HjumanwWthS+7168i0gxKs1QDd/F?= =?us-ascii?Q?JH9Nm2zzznKVu/eNp720uJycGM7wV3S8DcQtP8jyOGZCPOKWoMNXCk3KzNgG?= =?us-ascii?Q?+mLjwsQNjG7e5JfKo6OLU7nT+RmgJkYE1BKgnAMukPk9Z9TzieFPnK+bTILw?= =?us-ascii?Q?kOXpYrJCk1nvjbKolACIoBg62TrFopym4hCOFesR+VWzFyjilSzh2uEW8ybU?= =?us-ascii?Q?t6sC4aU+3bAij9OKYoVyDr42n0qKwuo9ACXguHJcQzA+U1TndrW7nXui5C1V?= =?us-ascii?Q?iMD4dEcYFIsDUHVj+aqkJiD9Op/ehMilS7T0D2JyLdAXDSltIcZGD0iAqRE8?= =?us-ascii?Q?KzWZ1JrB4m+BaxQSE9L2eVfVdU2YNvkHCr6QsSUp4sNtHRHO8Jt6ybzaAJ4f?= =?us-ascii?Q?KiOJq3HTWr4kKqyQ1iKWwpNBf4UgAY/tqEG5ZbVixA7ghhbt9N3EwxTKMRig?= =?us-ascii?Q?ZjnrvI+BaBfOLDMBIlNPZkwj1RIRaJlhWkdjCwuzthlh5xi/BrVs6wZ3U3q/?= =?us-ascii?Q?72VBo1KGjkwIP6YCwzG8u5ed60HU0Nk8BYXKBBmr7LSnIsJkTG3DqeE/z90s?= =?us-ascii?Q?cz+vxZB4hRheWsEwO4nsjdVDiL4Zj6rzMosmxUHx0uLxs5t1ZAyRG9nPvFUm?= =?us-ascii?Q?EG19oLSAO8Uw2H5ebx+wj5X7O4BLhLazmEq1krrQJu7mCRok52IRNK7TTQhV?= =?us-ascii?Q?aPmoZJaF8e5q+/ho2a/zIYgU2YOY4Vs3UVa2w7EuaozUGSuUcAMz5RP5YAtn?= =?us-ascii?Q?iFEgRIJbc0sRMTwBW+sSQuxKJ+yLo7AJlazEyCwEct/5f8ITJEISs2NgmOCL?= =?us-ascii?Q?heOnC9TiaAKvc5BwtdXffGff/YbVwnycP/Omsl4aliZ7ozyRkG2fEpn39W2g?= =?us-ascii?Q?9/nlj9oyWfDtFHpXKXgf8BiUNOAiimjTFUF9fqSW5k8rp+GvcmN+GBivcLfv?= =?us-ascii?Q?HTLqNHde5TukGAg9fzaRRTOG6zLuyI1Z82p4kQau?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB7177.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a236617a-9f3c-48e2-64ab-08db8fcd5127 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2023 00:46:59.5461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f67fVlF/WYzi5d3QkrX0wc6KM/dzl0f+Am6FPQdhaQwZZkQFy7kbKSFTfMkvDjEhR8gYUe/MJqlvROs2QyrjlOyfhXUsis1jroK/PmJ1lSc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4559 X-OriginatorOrg: intel.com X-Rspamd-Queue-Id: E9054C000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: onet68x1cxbqy9qyiwm5ku3ksk1ujg43 X-HE-Tag: 1690591629-454368 X-HE-Meta: U2FsdGVkX1/uJQJNqo1z34S3C/2VvqXSULR9p4yeE6Ew75uejsDwH8fuMJKKpOhnMYeYfLZXcwNuIpWElL5T7IOR25M4b5mXzyqgAWuTuwSxPyUa9UbHh5YapbrxU9J8KirU9ljWtBVCKEshsbZ0O/f7wpcunClBfBJPaJIgTpPl0maq667VMv0qNk7JgiyCjBGq+TV2yhMXRp7nJNv7yQPQySQxyS0Qu54uKZDLv56dqHDvVL+y6r6aRtYnHmX+sDSDXfKwuCGitq/yBimQqpe/z2JewwK3BXaL/RZv91HPBdaIZptCailrHvsD9munqdL15GqD6GGq+/p91Olhyqueew6/9ZpBriJMsCfrQ/p4yVGxRf1tWrPtye38jCqbA6H6mJZ8w4cWup5rGo0/r/v1DvrtHAGaUyKntxAAtaHgSddxPODoAdqdQ+9J72TAB+9hYPUsv2l6jEnkGNTAtMeh8W4Dp+h5i2Afl7dR+XUY2l+a/zBfyOBks+h4Z9Rgp2tvUgVXpkqANHqYTPKPWuMLbiQ+paSxk5QF4YYQEVifyJjiXfeNutGMwRjg9LmbW5hBD9llhkar9aV/E8aRrdWE09RVpxcQbBJKgiffsRwEYnV1KBjYsfGIGIlp5m6nhIgsvw7fGELZbpK9H7EWIhV5ZNdnA9vtzzcQ56MwIhxbcAkEWx6IehscnQib+Kjv5XFwV4g5YF9ljDwqB2bzMHtRBdJt9lfCDKS/Oy32fOUGuOy0ti9jQbkxUG5KMBmz21O4ZS7/0o+P1afiHhrx2lVnSBcvjuMJk/oSgiB9XehBFLS5Uq6TrbrE6ShltIIqbr8sybILRC0qMJ+Ld0A+4+n7y+MQZaw6p9eF0GVEqHAdGM4LaoYHy7rEH8c3BscO6d2mq/wdaweumTcTaXssb23Zo8Kb1DJw+VoOLPi67zl2ERb1f5rv04eBqUGqpK5+SKQ0JQmkVz7OragmvNg Yq/XBrnW l/mbsPlAYj3Z87nACUqphd/Cuj0CyoXgct2+9BMVYNr/+0JZbN3Y4+WtTA4mclC8xmS6YZhxyN1mR9aZDk7vARdzY6BUASCVIuAWr0XjPhWEX0SGcugeq0TXQU1S9YlzPviybZq1I3QOsz/OD5eYPoEPlgxycf9yh9Ly70omm2tOWtxik6mdkkw08Voc8EfMzL3XS21nSCQGWN5m/sLvYEfurcTP99mAjqxEgc5NjH7P9EhGq98U0vE3PvdQzUqw/KX+6jdOC8OmCtZWGjsKnCN9s0W7+jCb1pl0n7W92K42YgBmX/mjogOTJPSBKa3+gxBi/lOTgtevkeVrigR+z1aqPeukueQjha0jNdsx1fcmthPWxOq1DpkMAhtg/o2n8OhWBV74sV/cmjKSaC09f/0DF/anxuw7trmHmQ++SQgA6nMmpilp6hoivYhdjWntXeQZH22aMGcXDKNY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Jason, > > > > > If you still need the memory mapped then you re-call > hmm_range_fault > > > > > and re-obtain it. hmm_range_fault will resolve all the races and = you > > > > > get new pages. > > > > > > > IIUC, for my udmabuf use-case, it looks like calling hmm_range_faul= t > > > > immediately after an invalidate (range notification) would preempti= vely > > > fault in > > > > new pages before a write. The problem with that is if a read occurs= on > > > those > > > > new pages, then the data is incorrect as a write may not have > > > > happened yet. > > > > > > It cannot be, if you use hmm_range_fault correctly you cannot get > > > corruption no matter what is done to the mmap'd memfd. If there is > > > otherwise it is a hmm_range_fault bug plain and simple. > > > > > > > Ideally, what I am looking for is for getting new pages at the time= of or > after > > > > a write; until then, it is ok to use the old pages given my use-cas= e. > > > > > > It is wrong, if you are synchronizing the vma then you must use the > > > latest copy. If your use case can tolerate it then keep a 'not > > > present' indication for the missing pages until you actually need > > > them, but dmabuf doesn't really provide an API for that. > > > > > > > I think the difference comes down to whether we (udmabuf driver) > want to > > > > grab the new pages after getting notified about a PTE update becaus= e > > > > of a fault > > > > > > Why? You still haven't explained why you want this. > > Ok, let me explain using one of the udmabuf selftests (added in patch #= 3) > > to describe the problem (sorry, I'd have to use the terms memfd, hole, = etc) > > I am trying to solve: > > size =3D MEMFD_SIZE * page_size; > > memfd =3D create_memfd_with_seals(size, false); > > addr1 =3D mmap_fd(memfd, size); > > write_to_memfd(addr1, size, 'a'); > > buf =3D create_udmabuf_list(devfd, memfd, size); > > addr2 =3D mmap_fd(buf, NUM_PAGES * NUM_ENTRIES * getpagesize())= ; > > punch_hole(memfd, MEMFD_SIZE / 2); > > -> At this point, if I were to read addr1, it'd still have "a" in re= levant areas > > because a new write hasn't happened yet. And, since this result= s in an > > invalidation (notification) of the associated VMA range, I coul= d register > > a callback in udmabuf driver and get notified but I am not sure= how or > > why that would be useful. >=20 > When you get an invalidation you trigger dmabuf move, which revokes > the importes use of the dmabuf because the underlying memory has > changed. This is exactly the same as a GPU driver migrating memory > to/fro CPU memory. >=20 > > > > write_to_memfd(addr1, size, 'b'); > > -> Here, the hole gets refilled as a result of the above writes whic= h trigger > > faults and the PTEs are updated to point to new pages. When thi= s > happens, > > the udmabuf driver needs to be made aware of the new pages that > were > > faulted in because of the new writes. >=20 > You only need this because you are not processing the invalidate. >=20 > > a way to get notified when the hole is written to, the solution= I came > up > > with is to either add a new notifier or add calls to change_pte= () when > the > > PTEs do get updated. However, considering your suggestion to us= e > > hmm_range_fault(), it is not clear to me how it would help whil= e the > hole > > is being written to as the writes occur outside of the > > udmabuf driver. >=20 > You have the design backwards. >=20 > When a dmabuf importer asks for the dmabuf to be present you call > hmm_range_fault() and you get back whatever memory is appropriate. The > importer can then use it. >=20 > If the underlying memory changes then you get the invalidation and you > trigger move. The importer stops using the memory and the underlying > pages change. >=20 > Later the importer decides it needs the memory again so it again asks > for the dmabuf to be present, which does hmm_range_fault and gets > whatever is appropriate at the time. Unless I am missing something, I think just doing the above still won't sol= ve the problem. Consider this sequence: write_to_memfd(addr1, size, 'a'); buf =3D create_udmabuf_list(devfd, memfd, size); addr2 =3D mmap_fd(buf, NUM_PAGES * NUM_ENTRIES * getpagesize()); read(addr2); write_to_memfd(addr1, size, 'b'); punch_hole(memfd, MEMFD_SIZE / 2); -> Since we can process the invalidate at this point, as per your suggestio= n, we can trigger dmabuf move to let the importers know that the dmabuf's backing memory has changed (or moved). read(addr2); -> Because there is a hole, we can handle the read by either providing the old pages or zero pages (if using hmm_range_fault()) to the importers. Maybe it is against convention, but I think it makes sense to provide = old pages (that were mapped before the hole punch) because the importers have not read the data in these pages ('b' above) yet. And, another re= ason to provide old pages is because the data in these pages is shown in a = window on the Host's screen so it doesn't make sense to show zero page data. -> write_to_memfd(addr1, size, 'c'); As the hole gets refilled (with new pages) after the above write, AFAI= U, we have to tell the importers again that since the backing memory has cha= nged, (new pages) they need to recreate their mappings. But herein lies the = problem: from inside the udmabuf driver, we cannot know when this write occurs,= so we would not be able to notify the importers of the dmabuf move. Since Qe= mu knows about this write, I was initially thinking of adding a new udmabuf IOC= TL (something like UDMABUF_PREPARE) to have Qemu let udmabuf know after writes occur= . This would provide an opportunity after an invalidate to notify the im= porters of the (dmabuf) move. I think this would solve the problem with changes o= nly to the udmabuf driver (including adding the new IOCTL + handling the invalida= te) but I was hoping to solve it in a generic way by adding a new notifier or us= ing change_pte() to get notified about PTE updates (when faults occur). Thanks, Vivek > Jason