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 D3A6EC02180 for ; Mon, 13 Jan 2025 23:34:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F129A6B0085; Mon, 13 Jan 2025 18:34:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9B526B0089; Mon, 13 Jan 2025 18:34:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC6B26B008A; Mon, 13 Jan 2025 18:34:17 -0500 (EST) 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 A4DB96B0085 for ; Mon, 13 Jan 2025 18:34:17 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2793DAEC25 for ; Mon, 13 Jan 2025 23:34:17 +0000 (UTC) X-FDA: 83004034554.13.A605045 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by imf01.hostedemail.com (Postfix) with ESMTP id 0D90840016 for ; Mon, 13 Jan 2025 23:34:12 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SY5oNpmY; spf=pass (imf01.hostedemail.com: domain of dan.j.williams@intel.com designates 198.175.65.20 as permitted sender) smtp.mailfrom=dan.j.williams@intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736811253; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nJKwwErMumYDN8Wouu0Ayr8OB+AQpU/FzlUg/+dZkcc=; b=z96erJ7x+NjqNzkeAbVLF3RSIN8/4G/3gPS4u+hd+puo18ewJ6tUbn1vJcV0lFCz77TgZy b5R35P4kCx+N8+JO91bIa1T3G4YUHCpMU4mzniMY7iZ+870fNqjWe+bT7DJjML4qAkz+fh +sXjHZ4Jd4fJ2nteQYlDqYjkDZTxUAI= ARC-Authentication-Results: i=2; imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SY5oNpmY; spf=pass (imf01.hostedemail.com: domain of dan.j.williams@intel.com designates 198.175.65.20 as permitted sender) smtp.mailfrom=dan.j.williams@intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736811253; a=rsa-sha256; cv=fail; b=lg0rrRT5oZUCD4BsboPHTSWwzNEunzKpqj8GeBJnH0yh8XqWR7yAN7raCbCONHa38sPtPp rALDI0ToVZ/GtfdvpXC5XODxbwo+/CboWlxHwYGjz+v3w3e8VTfrwpkspplQzKQtWQZnUr aqnTRuIAA6z7ANuKaqNx3aJlykDZu7Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1736811253; x=1768347253; h=date:from:to:cc:subject:message-id:references: in-reply-to:mime-version; bh=rRldNJDABWS/ErMAb/fm2hco35qM8ZOEtP6kCr1vH6M=; b=SY5oNpmYgOpCaNeZ1mV+g9WlrJs+cMwUsXA590IzWT8QHQBBHZ0HAjfl 6JARMpz5wkp1IdFA7v6tnYUKTYg01m8KYvD+3zHfjHQwscbgOCKgaUKeN N3oDta7PzAzJH5XzBBSpDeAGfvatIJVbwzZdOYjHR15pHaCShzw8KnW0W GMBcqjX8zQI9JUiOjGwnhiA7/NM/jKDf9JqCtEsYcz8znZcsY1o1Rl9te LC2bXIgA0ieOxN/H5GMIrzl7RMXFkDrvo8CdjyWdUqihZJ7Kw7kPNU7kE 5DlLrPK96t9lBzyTlEzJGUNyoLfPpsBc7L0cXyVJBuWJH75VqOHlDHiZ7 A==; X-CSE-ConnectionGUID: EACzcSMXRvmhOf/YIxmiJQ== X-CSE-MsgGUID: JEkwzdVmRIi9VnlAJK+eZg== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="36783933" X-IronPort-AV: E=Sophos;i="6.12,312,1728975600"; d="scan'208";a="36783933" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2025 15:34:09 -0800 X-CSE-ConnectionGUID: 7BKw4ZPLR0WrMXaMJNIRPA== X-CSE-MsgGUID: 3O/c0vNkSQy2EaNxfBUkxA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,312,1728975600"; d="scan'208";a="105193901" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmviesa009.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 13 Jan 2025 15:34:03 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Mon, 13 Jan 2025 15:33:26 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44 via Frontend Transport; Mon, 13 Jan 2025 15:33:26 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.45) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Mon, 13 Jan 2025 15:32:44 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qRcnXvMfOP3s5lko/yDCkdufG76w2OkLO/k1n6kZ1RHQgeghuiZQFwpCRcF/O897C4q7PyC7vsLhqPmoWIe49kqbSKEx+Hxu4RBvmSZL9T0rYbgoLV25tK2eu8rua3xyZf4vKMpGbrTgo9tYKW28x+fEp4ZvPrjX5zqLvF/nie9Z3KMSHzAbhcXbqKu8OgGlkn6I/7xqwnTgGw+lUKJowI3iqA0A22FksKqNoPeNLXQxI7vdk1b87iL7/dm4xoMtqZS7p0rrFuwg2twOrm8v1IHGNr8FPO0BmTnuWiBzQsaBPrhH+24cgmWtZbwGhCpyMnHB0UjD261F8u/PcJpHpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=nJKwwErMumYDN8Wouu0Ayr8OB+AQpU/FzlUg/+dZkcc=; b=WbUiI4vdbFnlpMhP4ZRjLDGTMevrYZFvQuZK9zPpb8B1XBRZyQ9K4On1iHDFyRJL+w5p/5A5IQFOiwgXf+5AQQCu1bvWuI6t+JCGHh+euO1Vy1w5vS/pyq7uGNOn6wYQmNOn+Pl+z1fuaDoKRrDxTF5v08XFqylS7dnWynLP9NBKsgvb97NzWB2RPmmEMQI8cdanmDTC+fhLmsHh77NRLecYENgXKVNhWnGhzwWx4T6ZSlkKjDq2EL3T6GsBuooIU6irXwn8pdbah448XuE5js6+37/E7SP0P5vCTrob7wdMemZMviUu/JpHIrEvF4PbroXav7WB+gqXOp5Bw5tLog== 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 PH8PR11MB8107.namprd11.prod.outlook.com (2603:10b6:510:256::6) by SN7PR11MB6559.namprd11.prod.outlook.com (2603:10b6:806:26d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Mon, 13 Jan 2025 23:32:02 +0000 Received: from PH8PR11MB8107.namprd11.prod.outlook.com ([fe80::6b05:74cf:a304:ecd8]) by PH8PR11MB8107.namprd11.prod.outlook.com ([fe80::6b05:74cf:a304:ecd8%5]) with mapi id 15.20.8335.011; Mon, 13 Jan 2025 23:32:01 +0000 Date: Mon, 13 Jan 2025 15:31:57 -0800 From: Dan Williams To: Alistair Popple , , , CC: , Alistair Popple , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v6 06/26] fs/dax: Always remove DAX page-cache entries when breaking layouts Message-ID: <6785a26d48c86_20fa294d8@dwillia2-xfh.jf.intel.com.notmuch> References: <47bef43b54474a8ba7f266b9b5fc68ed91b1d7b8.1736488799.git-series.apopple@nvidia.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <47bef43b54474a8ba7f266b9b5fc68ed91b1d7b8.1736488799.git-series.apopple@nvidia.com> X-ClientProxiedBy: MW4PR04CA0291.namprd04.prod.outlook.com (2603:10b6:303:89::26) To PH8PR11MB8107.namprd11.prod.outlook.com (2603:10b6:510:256::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR11MB8107:EE_|SN7PR11MB6559:EE_ X-MS-Office365-Filtering-Correlation-Id: fa84e37b-649d-4aec-3194-08dd342a7b2a X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?M3MqWwqVFSPdKCzfDk9k08XOkKbEVKegAhrTY2/AcfbH7RThi8HG1EDtoALn?= =?us-ascii?Q?1djpLtKt4rdgdccyJzx0ufLh98GBhqy3OEquUGUK3d/e8oA5bwM0uwBOa6Lt?= =?us-ascii?Q?q9G86m8cCnmkZPdevX6G4iQRpi7X1vA46Uz+PP9igPgBAGCuusG87p6Tvl9u?= =?us-ascii?Q?f76+7Qh5ihbyw5TBvPkBNd5cUjDhUrJUh00+03VJCCb0qWvYENkEW68ZsIXs?= =?us-ascii?Q?f1krXnTbrKXceZOffa6Xv1YZiqz3E8z2Ma5S8WsLe68A/Ns9KVJOOM6C5sRN?= =?us-ascii?Q?5OoB9OfvbilXpk9J9aa+CBCyT4f70wqHZcS6M3VdQhR244GaWnziQeEsi3e/?= =?us-ascii?Q?y5edMVOBnGRFllh4xrRzHqAzKRAa/IHpPyVzDH4ziqAbl7kFpITc2xdl0Lbo?= =?us-ascii?Q?juXsrOeD0eaMqaHnzVrT4eK2CrxBwOqodXI55PFYfBFjXHX0SNKTv+4Jpaol?= =?us-ascii?Q?bs2zNF3RGrwv4aw/85qDI0MB5dCrSLzGXu28zCEYRb3EFhsX4hefnJiprDY9?= =?us-ascii?Q?3ujTWgurFN9CAzP9S7o/Iz5MNVigvShqPaCaxawuxDJhJELGZe67ZdYyIXR/?= =?us-ascii?Q?rCLagcPM60KBjh1oKGR+60ZEGfNC9PCwEOY5dMLzX3+ERdpwQm95/7qV0KmF?= =?us-ascii?Q?4+2PIuYRFcXSPb+SzS4uxZmcsf3Xuw3s164S4inyZeGroWHXFrOFusVunnzV?= =?us-ascii?Q?q1sL+TeGzYncBu4NkI19iozhssiTRJjUAVVrreET4cvHcs/0uHglDw6X34BV?= =?us-ascii?Q?9BU6eenmChaLcsAlUJJxIFETLN0UXSQjgzmbhBz948FjcF0Lxe3SvFyt0L6k?= =?us-ascii?Q?AMo4/HyPxgC9mohMTe2w5/Om5xwvkUhJFO+n6jajQ2ZCGoGE1Cyxnpid12QR?= =?us-ascii?Q?cLTX7H6RxLS2A5LJCAkUlCzwsXICgiRCM1UH/SVdzAKCrUuCUIhFhd6fqXIb?= =?us-ascii?Q?2xCqKnetHhQ30kjsQCCiPLIDrtAqLf8wZaBVM9Z1hOi0CYeHY2JGD/h5sDkN?= =?us-ascii?Q?lo2GqyGGnId4FeINYVrn8zsZhD1KDEGKfu9cEYp04Vlia3i0KwIJdeWDXzB0?= =?us-ascii?Q?GQWL9fqedh9ry0gMK11KTN1qLc7W2JdIjWlvOrZK/PL4M2LSu/UZew0Fb6u4?= =?us-ascii?Q?G7hm4RbnDWOgf8Z2nBgfjwmLM35yweraarUhHtt3v6LNGccl/5l6bVB1VXMF?= =?us-ascii?Q?BcJR07CJRCQfDShZbpyN6pdLftKRPKaI+1Ops8wVz54kjwTP8euWdi0BoJgq?= =?us-ascii?Q?fqAdkURuKT/bniS9r7G+h1iFK/8GvbBs+MoGqPSJHEl+ECn22XPjc1yYIXFd?= =?us-ascii?Q?0OLX4OFEYflOPd+DbokAYmWa9qjj+JCXH8LuVP1SEEgE1oEFKWeUriGyVwEo?= =?us-ascii?Q?kc7emO1lrQ+d8UP4a1c5aHlE79T0?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR11MB8107.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qp78a7pGpLaTo116YazmM9iLO1LKnON12TMyL0NtI5+i+hVACW/fUjvyx0jm?= =?us-ascii?Q?2AxfoZXDuoGOKd9pT2UD1aj8ZJV5q4v1mDZQy6ZW6ITYKuBJG3HJY/B6Z8dy?= =?us-ascii?Q?dAFd2ZapGV1uqcI4ytv7eNaUBxnwWmVCIaAkghuQVOo3JUELDCVMLg6l/lCU?= =?us-ascii?Q?L8g0fwRoz6PiBb19AY5Y/xEhpbYy01DWe1hiZHD6Bt2FDWlL0roDb5WFMr+B?= =?us-ascii?Q?TVqOa8x/XMfuf35n8r+q2fBfXv0jgeTetjUHBqtzNCmBXCf7LMyVJadZMdXW?= =?us-ascii?Q?Rg+qT4ePj/jxbFmst38Mt3oGq1UDHDf2dzCTaao5Ze+iqcX17ZJsLsmKiuX4?= =?us-ascii?Q?42M7QC5hff+DAwT1klZtZ/Gs+1gruv9AU8cZD+96Ub151k+dFqv9ZwFEs3Fe?= =?us-ascii?Q?IHB59ilrV9+pPP/Wa3fXHe2d5IStN0PQWsY1X61Hhf/kys7HeTB7YnmT0bJO?= =?us-ascii?Q?Xsyc8+DG3c0ftIzcDwbJxzWrcEy2M2PwhSbXNUn5PbDzmlQNWoePLgrL+kf2?= =?us-ascii?Q?NGCN9jp8e2ZR/+mbdQQ/shBIQ28wtqqMvVTiuB2Zrh4SCRP0s+y8oVoMQt1f?= =?us-ascii?Q?4cSmx7wJcktbOHw8i0csfgeVH+NUapO1b4i3wZ1QbSSW0eD2stDxTNlhlvaB?= =?us-ascii?Q?kFiYXAjI9o0yXkyYPgsdJ2cq0vG21dq5uLsJC4VeyeitNNkpNJ8os370Q/NL?= =?us-ascii?Q?EtJHS+4o7zLCDwL6NDN5k9YGGQAVPP8JptdoO+MNl2p/dTS1klyFDSk1JTym?= =?us-ascii?Q?hpZKrGzkGS3HM1vmfiEqsh2UOqhIRKvJK1GZqeNfkon+tHg+TRMZ10aFJ+3M?= =?us-ascii?Q?pNSWWV/QTEz1sWZaTsaw6VKfVhrmed6j7Wdq+r8TEvKob7OxhULJ940n5N2B?= =?us-ascii?Q?0zsAG+B9FY9+bgebJPz3juJ7IYKKP7Qr84EK0CX2qjmRTGgDP/9IXnc/aSss?= =?us-ascii?Q?qF2c5iLc8t6y8nFMSzTn7SSVTpQhg2Xu7NeMDRa1djLMkketrmVRl1FLovTX?= =?us-ascii?Q?8CDdnuxEeXvKyvydnXppBYTx2ew6akrPc1jZPbA4QbS504IHSiX4xjeEp+3r?= =?us-ascii?Q?rXp0oVe04jzJKZXCDDsW6aeb42a+y7JFdaPlqj83fcGT2XINK9lsiPFns8q2?= =?us-ascii?Q?93hedxMSTStS7NfJTZSZrQO+IcO2fL2C2vCdyGOhkc25HONZxIQnUvzfQzDc?= =?us-ascii?Q?kSqDSpm+M5NSXMrlj5CuIj2TK9LPUDE0vrZzh71kyA4WF5yDt//+yCPaN4oD?= =?us-ascii?Q?pJxI8pQpjyMgN3QnKmCfm5nTsxtkiD2QOGBzUHc1oeAUhfR8w9xpEva2cFIU?= =?us-ascii?Q?X4DIxMskUVS2NTduSSBFCx8kLsuJj/LH+H4xXHUTeH9KPypSkl8uyLz3tssX?= =?us-ascii?Q?/aGmmBEiWQ6Yt50rksdxMUppjCggv9Y8QsJZGVfl9jB9h05st7ixxhjgd89l?= =?us-ascii?Q?8QlLInbYl0i/puwsUDTKmrW1poB1jo9WRTnCHapTLGhsP5tjPOSv+vhLXj9q?= =?us-ascii?Q?Vnj1AxVxiYbngBCedZC6AgEO/tUQ7OHOU9OpSgdbpRfsyyUwVYPFTQN49/14?= =?us-ascii?Q?GyqPL6eYP9FXOUB4rGrM1ig9Brewt4RJIcrMA3WaCN5HMC++crpUL9XxSV59?= =?us-ascii?Q?Tg=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: fa84e37b-649d-4aec-3194-08dd342a7b2a X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2025 23:32:01.7743 (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: xDAA1ZDr0PpD/xo0OH7fjCo80k7U0A4Hi4yLDBIeFGjqf9GPqCqQPepGuQU8pd4xa/tuIXP5JnBHcQGJucmSaMpvh7GHQEC37cMC3tccEpo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6559 X-OriginatorOrg: intel.com X-Rspamd-Queue-Id: 0D90840016 X-Stat-Signature: h7zthy6xfoc3nwcet7c5sq9yzy3zrjoa X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736811252-724467 X-HE-Meta: U2FsdGVkX19b/GHBSDOP8iQ62TG+TFqNXhEIFZREZVt9BeqwyJR/Sa0foEh2Kv4eZ4pUaCRKJW6c35/jTK/UukMX7Qdv/TD+NcxGG8MJaaCttGtgeGyxpZtGZy+G3ZYMsGM/WUDMVZAN2yNjdS0LF7QlVgBOCz9Du9LJS1j+3SAtIoOWRA8WGDfzWR5Ap9p/JLaK4CItOs9ZUaKFn5Cg1L1cK2tvMa4aV+9qt2nmXGrZKg7jZs1IYdZ0YXd8f1Gh8nU8hF5zsYIrg2wiN1D5NmUE437w5o0xShE5wEakAs9233l/Q0ocvdxGI+Z7vy629tuUqnSdamq4wGnbYYt/Sp6q8VE0ApNln9rXovpwjsSIMBPqYno6gJUVMFsOHHix/O9/G0edbuE+IuUOa/wtQT07i556r4WIKhymZryqh4V6TM7qUL1af5KKiY4PHtedVqIG/U9Y7v53S+tfWfuJrm4cLr0YptYqP7kwmkTz75FdYX8JTfGtP8qKQzSLWgJkcdPgbqgywpcKO2aEvoVAPBzg5yObmdweGXxsQlCn5uORJoV5eC4NEk1SKD1iStK6LYpmqIH4JYayW6IIiWcsgW6p4VtFUba9+dbMNqWBRyzOWGRei+lbrqCNSgzfYqfTOKFQ+LrBzzD09iLP2Vkinqv4mXeh7HlOmB6/qmczX3/ncfXUo5a7Bf06/diatGguU5mhcpYV3BqLDSW/HDDQRQjubExm8pWURt1qlsX0XV7YHE+xnpALQqRAH+JP3rnEN/joydfVr7Xqb6ZLARoCfjb3Wo7azSePghmlaBtQyE2y0/0TJDXtCthkyh0HP/bE4GrX0Dqy7uX4T9ZGSqfc4blG0o7drLWeCVeIJagHHM1UArRcgjRhcY0Gefo49O6II4r0QBV7Zfzj5qowXy2OsbBzOcH+eVjvv61FV11ajd98wEoeasdo/nL4rjEHRYTKv0E4lM0B6v2dnQ1ZVK7 k7jcicoU YYLeWb8xHrol4xZ9DW/2EyXk18SYiUK/KX8Ng2pFzqAtCqsf3Wnzdfnpvfh34b6kGdolvmukPtm912eGGfY7ecFZi8ze+BUobqaF6gH4jCeToj1wJsTc8tO2rdUnRDO8GLrRKpqEe9qlsn6/tOTXsh7dLvNFQM+uYcyswpKTbPbtsK42UW/pN2dX6rUM+xPfbiDOvtmcAbDKAz+zQr0fCATIZV30y/hyKYXbsmSDNAWK8Pu0Xcmg93hMqzNrb4IfzVWkiEUXHqmVn/05ENQNISyoIJKxhJybrfa9nwP7rlbVUI0MridtzK1r0DpYfPcHMLFsaiRl6WX8ve9HM70W//1cjZJk93GWW6sYlmgC+7Whwy07nZPtsTmHJi8aD8bnp75z0p9otgUDMy+ordGqPaas2fVIBplSoLta6GUoaiO0RmK6qsasoEOVarSbCaB+dU+DyLSe2yRNzSiRBko78Ri8PGBYrRTaUz9WfHiNQQ8eh264ymxA7U2ft+/wuNgax6z2y 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: List-Subscribe: List-Unsubscribe: Alistair Popple wrote: > Prior to any truncation operations file systems call > dax_break_mapping() to ensure pages in the range are not under going > DMA. Later DAX page-cache entries will be removed by > truncate_folio_batch_exceptionals() in the generic page-cache code. > > However this makes it possible for folios to be removed from the > page-cache even though they are still DMA busy if the file-system > hasn't called dax_break_mapping(). It also means they can never be > waited on in future because FS DAX will lose track of them once the > page-cache entry has been deleted. > > Instead it is better to delete the FS DAX entry when the file-system > calls dax_break_mapping() as part of it's truncate operation. This > ensures only idle pages can be removed from the FS DAX page-cache and > makes it easy to detect if a file-system hasn't called > dax_break_mapping() prior to a truncate operation. > > Signed-off-by: Alistair Popple > > --- > > Ideally I think we would move the whole wait-for-idle logic directly > into the truncate paths. However this is difficult for a few > reasons. Each filesystem needs it's own wait callback, although a new > address space operation could address that. More problematic is that > the wait-for-idle can fail as the wait is TASK_INTERRUPTIBLE, but none > of the generic truncate paths allow for failure. > > So it ends up being easier to continue to let file systems call this > and check that they behave as expected. > --- > fs/dax.c | 33 +++++++++++++++++++++++++++++++++ > fs/xfs/xfs_inode.c | 6 ++++++ > include/linux/dax.h | 2 ++ > mm/truncate.c | 16 +++++++++++++++- > 4 files changed, 56 insertions(+), 1 deletion(-) > > diff --git a/fs/dax.c b/fs/dax.c > index 9c3bd07..7008a73 100644 > --- a/fs/dax.c > +++ b/fs/dax.c > @@ -845,6 +845,36 @@ int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index) > return ret; > } > > +void dax_delete_mapping_range(struct address_space *mapping, > + loff_t start, loff_t end) > +{ > + void *entry; > + pgoff_t start_idx = start >> PAGE_SHIFT; > + pgoff_t end_idx; > + XA_STATE(xas, &mapping->i_pages, start_idx); > + > + /* If end == LLONG_MAX, all pages from start to till end of file */ > + if (end == LLONG_MAX) > + end_idx = ULONG_MAX; > + else > + end_idx = end >> PAGE_SHIFT; > + > + xas_lock_irq(&xas); > + xas_for_each(&xas, entry, end_idx) { > + if (!xa_is_value(entry)) > + continue; > + entry = wait_entry_unlocked_exclusive(&xas, entry); > + if (!entry) > + continue; > + dax_disassociate_entry(entry, mapping, true); > + xas_store(&xas, NULL); > + mapping->nrpages -= 1UL << dax_entry_order(entry); > + put_unlocked_entry(&xas, entry, WAKE_ALL); > + } > + xas_unlock_irq(&xas); > +} > +EXPORT_SYMBOL_GPL(dax_delete_mapping_range); > + > static int wait_page_idle(struct page *page, > void (cb)(struct inode *), > struct inode *inode) > @@ -874,6 +904,9 @@ int dax_break_mapping(struct inode *inode, loff_t start, loff_t end, > error = wait_page_idle(page, cb, inode); > } while (error == 0); > > + if (!page) > + dax_delete_mapping_range(inode->i_mapping, start, end); > + Just reinforcing the rename comment on the last patch... I think this is an example where the s/dax_break_mapping/dax_break_layout/ rename helps disambiguate what is related to mapping cleanup and what is related to mapping cleanup as dax_break_layout calls dax_delete_mapping. > return error; > } > EXPORT_SYMBOL_GPL(dax_break_mapping); > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > index 295730a..4410b42 100644 > --- a/fs/xfs/xfs_inode.c > +++ b/fs/xfs/xfs_inode.c > @@ -2746,6 +2746,12 @@ xfs_mmaplock_two_inodes_and_break_dax_layout( > goto again; > } > > + /* > + * Normally xfs_break_dax_layouts() would delete the mapping entries as well so > + * do that here. > + */ > + dax_delete_mapping_range(VFS_I(ip2)->i_mapping, 0, LLONG_MAX); > + I think it is unfortunate that dax_break_mapping is so close to being useful for this case... how about this incremental cleanup? diff --git a/fs/dax.c b/fs/dax.c index facddd6c6bbb..1fa5521e5a2e 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -942,12 +942,15 @@ static void wait_page_idle_uninterruptible(struct page *page, /* * Unmaps the inode and waits for any DMA to complete prior to deleting the * DAX mapping entries for the range. + * + * For NOWAIT behavior, pass @cb as NULL to early-exit on first found + * busy page */ int dax_break_mapping(struct inode *inode, loff_t start, loff_t end, void (cb)(struct inode *)) { struct page *page; - int error; + int error = 0; if (!dax_mapping(inode->i_mapping)) return 0; @@ -956,6 +959,10 @@ int dax_break_mapping(struct inode *inode, loff_t start, loff_t end, page = dax_layout_busy_page_range(inode->i_mapping, start, end); if (!page) break; + if (!cb) { + error = -ERESTARTSYS; + break; + } error = wait_page_idle(page, cb, inode); } while (error == 0); diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index 7bfb4eb387c6..0988a9088259 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2739,19 +2739,13 @@ xfs_mmaplock_two_inodes_and_break_dax_layout( * need to unlock & lock the XFS_MMAPLOCK_EXCL which is not suitable * for this nested lock case. */ - page = dax_layout_busy_page(VFS_I(ip2)->i_mapping); - if (page && page_ref_count(page) != 0) { + error = dax_break_layout(VFS_I(ip2), 0, -1, NULL); + if (error) { xfs_iunlock(ip2, XFS_MMAPLOCK_EXCL); xfs_iunlock(ip1, XFS_MMAPLOCK_EXCL); goto again; } - /* - * Normally xfs_break_dax_layouts() would delete the mapping entries as well so - * do that here. - */ - dax_delete_mapping_range(VFS_I(ip2)->i_mapping, 0, LLONG_MAX); - return 0; } This also addresses Darrick's feedback around introducing dax_page_in_use() which xfs does not really care about, only that no more pages are busy. > return 0; > } > > diff --git a/include/linux/dax.h b/include/linux/dax.h > index f6583d3..ef9e02c 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -263,6 +263,8 @@ vm_fault_t dax_iomap_fault(struct vm_fault *vmf, unsigned int order, > vm_fault_t dax_finish_sync_fault(struct vm_fault *vmf, > unsigned int order, pfn_t pfn); > int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index); > +void dax_delete_mapping_range(struct address_space *mapping, > + loff_t start, loff_t end); > int dax_invalidate_mapping_entry_sync(struct address_space *mapping, > pgoff_t index); > int __must_check dax_break_mapping(struct inode *inode, loff_t start, > diff --git a/mm/truncate.c b/mm/truncate.c > index 7c304d2..b7f51a6 100644 > --- a/mm/truncate.c > +++ b/mm/truncate.c > @@ -78,8 +78,22 @@ static void truncate_folio_batch_exceptionals(struct address_space *mapping, > > if (dax_mapping(mapping)) { > for (i = j; i < nr; i++) { > - if (xa_is_value(fbatch->folios[i])) > + if (xa_is_value(fbatch->folios[i])) { > + /* > + * File systems should already have called > + * dax_break_mapping_entry() to remove all DAX > + * entries while holding a lock to prevent > + * establishing new entries. Therefore we > + * shouldn't find any here. > + */ > + WARN_ON_ONCE(1); > + > + /* > + * Delete the mapping so truncate_pagecache() > + * doesn't loop forever. > + */ > dax_delete_mapping_entry(mapping, indices[i]); > + } Looks good. With the above additional fixup you can add: Reviewed-by: Dan Williams