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 115EFC021AA for ; Tue, 18 Feb 2025 23:30:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AC292801B2; Tue, 18 Feb 2025 18:30:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 932EB2801AE; Tue, 18 Feb 2025 18:30:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 785782801B2; Tue, 18 Feb 2025 18:30:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3D21E2801AE for ; Tue, 18 Feb 2025 18:30:44 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D6D97B1246 for ; Tue, 18 Feb 2025 23:30:43 +0000 (UTC) X-FDA: 83134662366.24.C354E63 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2075.outbound.protection.outlook.com [40.107.236.75]) by imf28.hostedemail.com (Postfix) with ESMTP id 12C4CC0002 for ; Tue, 18 Feb 2025 23:30:39 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=YxJNsa54; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf28.hostedemail.com: domain of apopple@nvidia.com designates 40.107.236.75 as permitted sender) smtp.mailfrom=apopple@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739921440; 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=2/XyJ/5W8cVygXYbZ0B/91iqdi7aL/7aKRbIbKxcsbM=; b=Sl90Ep/E9NGLouSd1dMAfYsXYcahJ4VyFrYYEknUCa4f/Wk8dRCX4vPwXr2mUflW6V3EI1 35b1EdVQJCKlwth8rJ7ZBkzzw1p59X1buV/L31rKDqeJUTiowAM3ZED5pTIvP/bRVZTGMT cKgaCWTBol/EuF41+MyA+/4ljO2iYuU= ARC-Authentication-Results: i=2; imf28.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=YxJNsa54; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf28.hostedemail.com: domain of apopple@nvidia.com designates 40.107.236.75 as permitted sender) smtp.mailfrom=apopple@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1739921440; a=rsa-sha256; cv=pass; b=6KKkSSYA0s61jlpkcDuu7WP1zxP5Jl0NVQvXlh4hfvJ7nuncJCCIG9c17Jxw/qrMfMmJl6 o65/4qHA23plTnVlYMMkaqMRBCoshmuK8ETYjGfIyCWsavo8WmZi/0XewQJNkdEA6t9aDa o9DCs2wV4Gm9HU6/ASQn4voOlWr2YBY= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Sdalyx0fOmu3Y7bqHq1me5Y9l4Gn8ZvxkPybia+7Gn80peSCktX8XyeGO90cGG7dkJ7IH5N/9onehhWqv/w0RexbERtj8VJZNRtMFsbOw0YEHfJ7faI9uiChVJwj2p0euG1qb/Hi1ei/fCO0Qt7UOfzb6VbTdY8eL2kuEosB7QNLYkI6bRr7eD9o2CHGS2WZLLFxDWTLmWqSKPmVzUFOW1+vvQFWqZ1LKrEWV6a4IkwW+Ms/ZJTHQW4TLclMwb7oFfSj2Qn4X8sz/b8C8DGgob0qnaKyhRONsUCzngNHmNpTeevDFSpVVfLG0HLjc2e7xk4ntt4dUUmqINHzSW5L7Q== 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=2/XyJ/5W8cVygXYbZ0B/91iqdi7aL/7aKRbIbKxcsbM=; b=P6XdkBAHFmMf2InrZ5MMovAnPniTpvmJWPvJihFXmcgPnGPAsKNzDiIHiHPmnzxQV3wjr+MtHE47J8n87BAnzYPRTzWCfc7T0ljhCcb8P0Ch6LOBKOV3eASApCjDdGphUeibYnKHDq/9fILOXF2cS6G6/+24rEX+RmTk+2J9aRhhCw8QofhplewuCzZdKJzdDnychNhLht9v5Iptfy5Mnb3F4PuXgazjI2Ret+Qw8vLuS0iit78jLSS89R0+pKcV2u96dnF5Xjj2wMFkkoD4xWH+Fs48jGqUt0C2RemUtUuBOtmrt5mrQt/AfaU8qXOzUbvRDLRtC/SefS4GeM47Mw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2/XyJ/5W8cVygXYbZ0B/91iqdi7aL/7aKRbIbKxcsbM=; b=YxJNsa54cUwCQuJiCsZxElCE59BV99j6elyXtO2ATFQwTBwWZ+r68+Epm/Aeca3a1yz4B9KGlxjIkzTzLeMaSVwrqEmO9LpkNUUDsYnV+yJ32PzETNJEi55l7hNBp1RDKTcEAOHB/ovN9Hls0NwX43zHbwScTQ8Zak7CvJmakZnoDL4YA2+ec4LGKZZ2+H5ok6bxEvd5jOeGm6GGLn0I9MD3986TsXbs4VZ6OHo11ahRWD1qRaHX4BfnKFJwzbtYVWaVjuPjEdKLuySnXy3vi7E7KrunpUEwzMglIFA4nOXRlVO6BuUqWtyHC9PR4HTS+XMb/JFMxC7Fog1GPnXJMg== Received: from DS0PR12MB7726.namprd12.prod.outlook.com (2603:10b6:8:130::6) by PH8PR12MB7232.namprd12.prod.outlook.com (2603:10b6:510:224::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8445.14; Tue, 18 Feb 2025 23:30:36 +0000 Received: from DS0PR12MB7726.namprd12.prod.outlook.com ([fe80::953f:2f80:90c5:67fe]) by DS0PR12MB7726.namprd12.prod.outlook.com ([fe80::953f:2f80:90c5:67fe%7]) with mapi id 15.20.8445.017; Tue, 18 Feb 2025 23:30:36 +0000 Date: Wed, 19 Feb 2025 10:30:29 +1100 From: Alistair Popple To: David Hildenbrand Cc: akpm@linux-foundation.org, dan.j.williams@intel.com, linux-mm@kvack.org, Alison Schofield , lina@asahilina.net, zhang.lyra@gmail.com, gerald.schaefer@linux.ibm.com, vishal.l.verma@intel.com, dave.jiang@intel.com, logang@deltatee.com, bhelgaas@google.com, jack@suse.cz, jgg@ziepe.ca, catalin.marinas@arm.com, will@kernel.org, mpe@ellerman.id.au, npiggin@gmail.com, dave.hansen@linux.intel.com, ira.weiny@intel.com, willy@infradead.org, djwong@kernel.org, tytso@mit.edu, linmiaohe@huawei.com, peterx@redhat.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, jhubbard@nvidia.com, hch@lst.de, david@fromorbit.com, chenhuacai@kernel.org, kernel@xen0n.name, loongarch@lists.linux.dev Subject: Re: [PATCH v8 19/20] fs/dax: Properly refcount fs dax pages Message-ID: References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: SY5PR01CA0067.ausprd01.prod.outlook.com (2603:10c6:10:1f4::14) To DS0PR12MB7726.namprd12.prod.outlook.com (2603:10b6:8:130::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR12MB7726:EE_|PH8PR12MB7232:EE_ X-MS-Office365-Filtering-Correlation-Id: f144e0c2-c18e-42a0-a963-08dd50743ee5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?B8Bg1YJLTPRDgKHtsLsN1NEeXyhR0EsIArOhprAvM+b9ZKTkLgW10lmcysoj?= =?us-ascii?Q?MPZCaFMAY6TXGzhQn0vWFYx4QNa/wMKYP9c4FzqnymiZOzKJKO0mpWDBe3X/?= =?us-ascii?Q?LGFjDwCVKgiwpgTy3CsZIRmQGWdiSzwtORcwTyOmSrxgyBQdgTkEPBBWUhpt?= =?us-ascii?Q?YHw1o3qBPiMKn89CMNz9EPUfgv31EG8CKQBw/7QyexnYzEz5rGGumFg+eaNo?= =?us-ascii?Q?AnltLP8JfzMtC4BPyqQivZ+qGHj/NRsML+2env1B1+Vpz3CaePaeeRuE837a?= =?us-ascii?Q?CarHI7xKHHFHq3hXd509yj9QebQkL5E3JfOXYQM2HoZgS/Vqm7FgF0sFyp5A?= =?us-ascii?Q?yjdn0jm2GBFTPi0MMBtvL9FsCQnA91TCbP9yjXQ5Sf7DBYuZsMAyJpCV9+Ab?= =?us-ascii?Q?uSKyr/wK6BVFK/fNYTm1LEDLD6Pus6gnff/418vq+VY1RSPRdos6CDs8d8KB?= =?us-ascii?Q?Gg+6PlzmkS499Xo5bwCMRpzFFInKU/CFuFmTVWX+tE5U7/r9hYxXgpPpuHy4?= =?us-ascii?Q?Ua/U6FQgzREoTqgdPmwJ0GLFTzBaxHERXg8DCgX3WRK/W/ZpaWLPpMSrLqLn?= =?us-ascii?Q?b8kl6vu2A8ntejzHEHUe094cwJalEskcL5QYvaPpE91EyOUuGc3pWWXwEuxD?= =?us-ascii?Q?6BxgZBpdB/tAoTkmjzgDh/+xoHyLpKIcx1Fz+5VdkJEPi7g9qrmtxmkHa8TV?= =?us-ascii?Q?1i11/27p8T6J1pbzgsVd9jZJiJ7n7ZQYfmuE5blTbPn6eaR5Y5lcB+ZJB9R3?= =?us-ascii?Q?//+Sad2L9+dgYEm2wjHXaGnQygwDlLu28tN8fMiXalUy06dWvKTveS/Thxwa?= =?us-ascii?Q?2VdK/sTcs89aBiZuRv2VvLzl269ng/ZIr+HCxkIrmRpbjCxn8jKQF/PZkhpp?= =?us-ascii?Q?VOtes5AC4dARSRoWtW6Aye/QUigsnnWzd4w7AztkrUmoFCkMO5eWQiZmLtzU?= =?us-ascii?Q?bGTUgOKStWzjXsnYgolohzpCIw3Ed2pDlEovoQAnWWm864REZ0q5vyeBuEZX?= =?us-ascii?Q?iNcEVW62stsZyL7s/k+KIW1QeBE75ddefnYERigL6biloUHYJ/w19W+YkjiL?= =?us-ascii?Q?YgJjU7Jp5W5+FRBaVwpr/cvdk5RnQrbL1w8YvAKuE3idSVY/x6/8gnQ8dNdL?= =?us-ascii?Q?Pa8o/UGaI2CMFbTg97f4BRiSa6vzlwxDWHuB75XyHOhkDA1bnA0ESCQuF5ie?= =?us-ascii?Q?TBK+6m4wMc43y5iKHK2o1HUNuwZguTIuMRSgXtDJhy5iFkuzbsaWOgjqoGtL?= =?us-ascii?Q?hDtwVs8zpYN64923KIHQGEgQuHewDZ5JE9VpDUDRKr3y9GNTnLLTv7oqDwJ7?= =?us-ascii?Q?V0ucPe34vpNvKj/GINMm/w19Qxz71tbj6/Y+M/BgyQEuMdho1asttv291g4V?= =?us-ascii?Q?2Dc9lgfc0D7/+3ICp5nppC+3xkRo?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR12MB7726.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AFZ1WnU71rH2mPJwtoKq7rs7IsJILwQ5zuEDAA9BESk6eJzy08JyrAFY2l3J?= =?us-ascii?Q?dTUZ60x5biq1VUU53HbajjnanCevOB1HrGfzyNkJ4NCO4q59WF4c8X0ltrZt?= =?us-ascii?Q?Lel78JG8eRK+4q9myh/GjvdVy31ws7euchMkLIqptqG2FGjT3OmGGfwhJGpu?= =?us-ascii?Q?SRYK2BkBq2paK8Xe+/7eJpdWmKdnRP9dWdCTrDf1gGqbvtaXf6tWvAYS3BJ3?= =?us-ascii?Q?mPNRV4yE46Lr2b1E8J3fRQ1Jhvqsr1gfRDMR4TMXqNPSuUgzA7mea0xy3lFK?= =?us-ascii?Q?GRyPxYs24y5fnW7X/YRJkk0LiCNC3usd1dhnKzPSyTxx3PzZ6odU7YulOuMz?= =?us-ascii?Q?kAkNplXOB7rhBKYat/vm9/T2UmZzmpTfucMe4zh8oaMxexRRQi/2VxZJjFwt?= =?us-ascii?Q?4MENi8s3qhO8j31qeb3leSmFK2jQkbau18iuD//6Xq8368WQf40IUD8N+xPE?= =?us-ascii?Q?SIETt7KfIM8IwABYVpVq+1JjHGt8WBGWyX+yhHJN4rhLtFjHJmHbPyWkE+ll?= =?us-ascii?Q?h2YAv8vbs/IEjPagCItp0PCo9QRXeTnGsW1Dz6aY9dFr473+mKENJCyLmMms?= =?us-ascii?Q?DsYWm1pYFjFbCz5ElH+Y6rgqwF/e4EppkfaxFjVYcDMqnf++sZMwlVnJRo7z?= =?us-ascii?Q?K9361uGgZPdh7lVlbPB6d+61ELBm/yH2RPjF8X2T7DotKWcxmVAIFOmc7KME?= =?us-ascii?Q?PxN2gWB5qqRj5Qxv6YX7ZdMsh3Oz7NZEeoDC6nXTCQiUly++AvSrtDKktJbf?= =?us-ascii?Q?KItmja2RrIL7LrROy7v2PC2andQns6P4iDORQcgdxgACS63oMuyccmzQYa4E?= =?us-ascii?Q?xfkgq+Ee8VjUjmaQt3MDbSeCUKjglMzANR4hybvtVCJJl5x+uBGQdBprrmO8?= =?us-ascii?Q?OLeBPmMe7A9KAsTqTy7nFxYOLimcgWCcgSKzR9pF34PbaYSbK0LzeAHV8pXd?= =?us-ascii?Q?UgZVitiFy0rpdAnnp/qX/jxehsh4PJ4k1XJyrfq0emmD2e4HTJ7tRYCfXFWD?= =?us-ascii?Q?0xZF2fYqScVuWJcW3+gWYTt+np1d1jOHEN6FFiqwYol1HgVdZep9rV22wPxk?= =?us-ascii?Q?OVl3+ebrHPcbPoeXGMETiUsMuV94QlQX86MF78VnB7ltNXV00EAVmGvvuF91?= =?us-ascii?Q?W5tH111L9pWimpPrssS9yxOXsvaC8NEZjz65YAjqx38zwKGyU6AbnnHTHPTO?= =?us-ascii?Q?aszRF94U4NHABfKtNGHJ6CrU/A3FxirSy8ox9qXHfnAaA1Y/IWwzFy7pyLu/?= =?us-ascii?Q?aUOECZmjefYgrDtmjEVIIvaahbOShCG5ZkazHOMGwW35XeDGZ3hmRUssoetp?= =?us-ascii?Q?LmQPx5ebK570yr0fhETc68omSjvJw6mUEwW4KAH/Q8B8zFx//d+0fmhX6e72?= =?us-ascii?Q?NCTWmhkul+9t6IuQZ6nTS6eMEIEpQGaj59fPXK3+2Q5KW9dtd0lTVb8RX6Pn?= =?us-ascii?Q?LJntTm7g4egElGaZgV2KMTkKVLkLh29QBDq49/jziYS5nGvbqSQijP7nTJoa?= =?us-ascii?Q?CHfzU9lBhpnVb49dbH42LMVAUkKG+60cTXbNuNEWJ5aBGvZPWV2pGSRQAs0k?= =?us-ascii?Q?ptPdoRhDpJDKGaFojvO9mNTIGb3byAdMX9KUZKyU?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f144e0c2-c18e-42a0-a963-08dd50743ee5 X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB7726.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2025 23:30:36.1511 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SAopfzQAHOOceK1PA9oRQjU3aGEjspGPSTQSEvuns34urOdrhYOOxmOaHKnMl+UicCxF7QVcKSbvjxdYCyp8gQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7232 X-Rspam-User: X-Stat-Signature: bd9zq8bicpy7asakwq8ydqydsjfjiifb X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 12C4CC0002 X-HE-Tag: 1739921439-295188 X-HE-Meta: U2FsdGVkX19vDWZCe19ks4r53v71xszWL+I7LWDDxlYdgnQL4H5iDgVKI3GPYHi40D6UZFotPhogDVqr8qhNbNlqVF1kdEFRNNDmK19BtQw7fNoCZl2WV/nvzTdVUH+Ad9Errbol1Mjig1WU/T00Ofi8VFKzqEgAzeAJSJsFj42eOPK6H5jyx1wI2Pa6O61tuXmVDoDEY+fa1u5KULSY355ShcvCE4Q+IpYetZRj1b3vqQvx7Tj8hXJ8/5VzSYsN3JPeyydphsR1+VJ/DQnwNRNUYQZaTNeBsWQeygS2+hZHfhG5F8y9N04r8YLCXLqynnabHouUvSg0/mRGCMe93ZtYZp9YMNVE/ss6PCdQH4i31xgkxhtRSb/PaBeYUFTc9NSrxzubsGto586DnS0nJB9Fp4M98mXjG2PVbP0TtU/tWIkQ5qvcF/bjRETArIN1VvP4g+cafFVh9bH19w+2vLkw/fXVEda/KVrBMNSsz3J+WQAdtBxzUnnRGliEdE/5t3MujeRjmQZjsEetYAOUcFC4zF0uGZaLp4SPL7YNGnj+WpIWjUXGUeG5N8hHy+mLSYAZs/FHBHOQphysZKdkbq4ENarCylpNFhonzdodGMz15Ollg2vD1/829GWADnajJov/xYF2LZCGnjyc7b5BO6qWLacydE3v7+Kj9s6c/FVpfCHOF1BJihOxYjrnx3U5VCuXEhPBxcCQ1t0fHfVc86T6nJdlpGvOfC/7dAPGtIMa8Dwtw31v9PYeYNSE9hSnkdH+bMyMioVrezvh1XG5wdD+mdwbYiuSQTfzf23PZJB1brGqqVBVELUBKlVIPAdOsOHWjkcse7OKz1gfCFz/L2k+KxDoFXMHTzG9VKo7cVu+iLEgnjfmAEmvsQIRyglHFlUMFjS9/4tIS0nVjd/q4OmKgnPUa4B4pHerwZPvC3JaGYsGU9OgX5zD4Zsvt51YBoVvFFDQqWtkF5Xz3ye IVaOL447 vMuypVR1YNeq/P6KgOoAa6eMZGiK9nvTbkatCIbMQbFN17DzICWX+1aBOXQ3JgWaS/5VVXIcO7imkY6fzfvy4lq9kjtt/ksfzWWzsG/CRcmIgsLEsW9izTR1YWN7Fm/k8m6NTVXevv52QqwMizDpJswWWONBdAs9PiC1xtcnibiAku+NdA4c7DUwkzHCYf862CCdpEzDW5gMW4Zr33vwpoABuvv+Jj1rKaMwOnTBJXYhFy9MdY7Efv4rH08HrHSMPFfctKJj5Vizbl4qUlV773dax4OCF6xSKdq++RWK4252EVcAq7h1dY8ELifKrTSHz5nX86AuxrFh82vqN3OjoBAOUNuSvsk5Bpw4cNbJKjlK4RfXv2fTHfQIo7gDPD2pz5896vIkVTjGjh1++6ITU4MExq17XhYiCrGd/OX9WwPTQRh7jqg95jk1YGm0g1W43Sr4zJSmLHq8ZxRiXJaIwoGgNGYMG96FFYrKh 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: On Tue, Feb 18, 2025 at 12:37:28PM +0100, David Hildenbrand wrote: > On 18.02.25 04:55, Alistair Popple wrote: > > Currently fs dax pages are considered free when the refcount drops to > > one and their refcounts are not increased when mapped via PTEs or > > decreased when unmapped. This requires special logic in mm paths to > > detect that these pages should not be properly refcounted, and to > > detect when the refcount drops to one instead of zero. > > > > On the other hand get_user_pages(), etc. will properly refcount fs dax > > pages by taking a reference and dropping it when the page is > > unpinned. > > > > Tracking this special behaviour requires extra PTE bits > > (eg. pte_devmap) and introduces rules that are potentially confusing > > and specific to FS DAX pages. To fix this, and to possibly allow > > removal of the special PTE bits in future, convert the fs dax page > > refcounts to be zero based and instead take a reference on the page > > each time it is mapped as is currently the case for normal pages. > > > > This may also allow a future clean-up to remove the pgmap refcounting > > that is currently done in mm/gup.c. > > > > Signed-off-by: Alistair Popple > > Reviewed-by: Dan Williams > > A couple of nits (sorry that I didn't manage to review the whole thing the > last time, I am a slow reviewer ...). No problem. I appreciate your indepth review comments. > Likely that can all be adjsuted on > top, no need for a full resend IMHO. > > > index 6674540..cf96f3d 100644 > > --- a/fs/dax.c > > +++ b/fs/dax.c > > @@ -71,6 +71,11 @@ static unsigned long dax_to_pfn(void *entry) > > return xa_to_value(entry) >> DAX_SHIFT; > > } > > +static struct folio *dax_to_folio(void *entry) > > +{ > > + return page_folio(pfn_to_page(dax_to_pfn(entry))); > > Nit: return pfn_folio(dax_to_pfn(entry)); > > > +} > > + > > [...] > > > -static inline unsigned long dax_folio_share_put(struct folio *folio) > > +static inline unsigned long dax_folio_put(struct folio *folio) > > { > > - return --folio->page.share; > > + unsigned long ref; > > + int order, i; > > + > > + if (!dax_folio_is_shared(folio)) > > + ref = 0; > > + else > > + ref = --folio->share; > > + > > out of interest, what synchronizes access to folio->share? Actually that's an excellent question as I hadn't looked too closely at this given I wasn't changing the overall flow with regards to synchronization, merely representation of the "shared" state. So I don't have a good answer for you off the top of my head - Dan maybe you can shed some light here? > > + if (ref) > > + return ref; > > + > > + folio->mapping = NULL; > > + order = folio_order(folio); > > + if (!order) > > + return 0; > > + > > + for (i = 0; i < (1UL << order); i++) { > > + struct dev_pagemap *pgmap = page_pgmap(&folio->page); > > + struct page *page = folio_page(folio, i); > > + struct folio *new_folio = (struct folio *)page; > > + > > + ClearPageHead(page); > > + clear_compound_head(page); > > + > > + new_folio->mapping = NULL; > > + /* > > + * Reset pgmap which was over-written by > > + * prep_compound_page(). > > + */ > > + new_folio->pgmap = pgmap; > > + new_folio->share = 0; > > + WARN_ON_ONCE(folio_ref_count(new_folio)); > > + } > > + > > + return ref; > > +} > > + > > +static void dax_folio_init(void *entry) > > +{ > > + struct folio *folio = dax_to_folio(entry); > > + int order = dax_entry_order(entry); > > + > > + /* > > + * Folio should have been split back to order-0 pages in > > + * dax_folio_put() when they were removed from their > > + * final mapping. > > + */ > > + WARN_ON_ONCE(folio_order(folio)); > > + > > + if (order > 0) { > > + prep_compound_page(&folio->page, order); > > + if (order > 1) > > + INIT_LIST_HEAD(&folio->_deferred_list); > > Nit: prep_compound_page() -> prep_compound_head() should be taking care of > initializing all folio fields already, so this very likely can be dropped. Thanks. That's only the case for >= v6.10, so I guess I started this patch series before then. > > + WARN_ON_ONCE(folio_ref_count(folio)); > > + } > > } > > > [...] > > > > } > > @@ -1808,7 +1843,8 @@ static vm_fault_t dax_fault_iter(struct vm_fault *vmf, > > loff_t pos = (loff_t)xas->xa_index << PAGE_SHIFT; > > bool write = iter->flags & IOMAP_WRITE; > > unsigned long entry_flags = pmd ? DAX_PMD : 0; > > - int err = 0; > > + struct folio *folio; > > + int ret, err = 0; > > pfn_t pfn; > > void *kaddr; > > @@ -1840,17 +1876,19 @@ static vm_fault_t dax_fault_iter(struct vm_fault *vmf, > > return dax_fault_return(err); > > } > > + folio = dax_to_folio(*entry); > > if (dax_fault_is_synchronous(iter, vmf->vma)) > > return dax_fault_synchronous_pfnp(pfnp, pfn); > > - /* insert PMD pfn */ > > + folio_ref_inc(folio); > > Why is that not a folio_get() ? Could the refcount be 0? Might deserve a > comment then. Right, refcount is most likely 0 as this is when the folio is allocated for uses other than by the owning driver of the page. > > if (pmd) > > - return vmf_insert_pfn_pmd(vmf, pfn, write); > > + ret = vmf_insert_folio_pmd(vmf, pfn_folio(pfn_t_to_pfn(pfn)), > > + write); > > + else > > + ret = vmf_insert_page_mkwrite(vmf, pfn_t_to_page(pfn), write); > > + folio_put(folio); > > - /* insert PTE pfn */ > > - if (write) > > - return vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn); > > - return vmf_insert_mixed(vmf->vma, vmf->address, pfn); > > + return ret; > > } > > static vm_fault_t dax_iomap_pte_fault(struct vm_fault *vmf, pfn_t *pfnp, > > @@ -2089,6 +2127,7 @@ dax_insert_pfn_mkwrite(struct vm_fault *vmf, pfn_t pfn, unsigned int order) > > { > > struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > XA_STATE_ORDER(xas, &mapping->i_pages, vmf->pgoff, order); > > + struct folio *folio; > > void *entry; > > vm_fault_t ret; > > @@ -2106,14 +2145,17 @@ dax_insert_pfn_mkwrite(struct vm_fault *vmf, pfn_t pfn, unsigned int order) > > xas_set_mark(&xas, PAGECACHE_TAG_DIRTY); > > dax_lock_entry(&xas, entry); > > xas_unlock_irq(&xas); > > + folio = pfn_folio(pfn_t_to_pfn(pfn)); > > + folio_ref_inc(folio); > > Same thought. Yes, will add a comment, either as a respin or a fixup depending what Andrew prefers. > > diff --git a/include/linux/dax.h b/include/linux/dax.h > > index 2333c30..dcc9fcd 100644 > > --- a/include/linux/dax.h > > +++ b/include/linux/dax.h > > @@ -209,7 +209,7 @@ int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero, > > [...] > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index d189826..1a0d6a8 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -2225,7 +2225,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > > tlb->fullmm); > > arch_check_zapped_pmd(vma, orig_pmd); > > tlb_remove_pmd_tlb_entry(tlb, pmd, addr); > > - if (vma_is_special_huge(vma)) { > > + if (!vma_is_dax(vma) && vma_is_special_huge(vma)) { > > I wonder if we actually want to remove the vma_is_dax() check from > vma_is_special_huge(), and instead add it to the remaining callers of > vma_is_special_huge() that still need it -- if any need it. > > Did we sanity-check which callers of vma_is_special_huge() still need it? Is > there still reason to have that DAX check in vma_is_special_huge()? If by "we" you mean "me" then yes :) There are still a few callers of it, mainly for page splitting. > But vma_is_special_huge() is rather confusing from me ... the whole > vma_is_special_huge() thing should probably be removed. That's a cleanup for > another day, though. But after double checking I have come to the same conclusion as you - it should be removed. I will add that to my ever growing clean-up series that can go on top of this one. > > -- > Cheers, > > David / dhildenb >