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 E4F18C02192 for ; Mon, 3 Feb 2025 15:45:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56AC86B0082; Mon, 3 Feb 2025 10:45:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 541556B0083; Mon, 3 Feb 2025 10:45:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 394A86B0085; Mon, 3 Feb 2025 10:45:11 -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 15DA06B0082 for ; Mon, 3 Feb 2025 10:45:11 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B8F6A1601B6 for ; Mon, 3 Feb 2025 15:45:10 +0000 (UTC) X-FDA: 83079057180.29.D7C9B5C Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf22.hostedemail.com (Postfix) with ESMTP id 49B49C0002 for ; Mon, 3 Feb 2025 15:45:07 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=Qd960XDK; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=hWTRKA4h; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf22.hostedemail.com: domain of liam.howlett@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=liam.howlett@oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1738597507; a=rsa-sha256; cv=pass; b=oe3ZuALHqwtxlLt2hwTs6Qv6H6+AXAkwEGqukV+TJEnw5ADcQyDLJjEdXT5NjTSuGvdXIv BDRej0RbzoP9VNXKC3lKdHYqCq7G6IuVoKQyjhPBPS0FWlPfu5v7bnFxeLwRrVy0UM7KxQ x+Q+JK8aoNt/QW1nwDqHtU1kH/GJ7mM= ARC-Authentication-Results: i=2; imf22.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=Qd960XDK; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=hWTRKA4h; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf22.hostedemail.com: domain of liam.howlett@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=liam.howlett@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738597507; 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=vLg+yAyJ9yrlE2alTI++zuch7g5ozhWQTbKehwGTt50=; b=1pVFcu7tthDGm35idplwhJ5UHb3LkKlBexdzH+n0gljVIjtMSJK7Em6a+w72S2+UxCJf3k iGG07YcJTopv3qQtG0XYuEfkyXuVCOrRZkwElkj4o9XIlfaO8wj9DnLlhHZbzxJ3aLDWc6 jgxBTL19Q8b2u7oKO/PH2bSEh9//6Hg= Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 513EBqwL021844; Mon, 3 Feb 2025 15:44:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=corp-2023-11-20; bh=vLg+yAyJ9yrlE2alTI ++zuch7g5ozhWQTbKehwGTt50=; b=Qd960XDKwtAR3bXNAEXnRFU1Z4d0ppjOkC r5/ja00uULBXV4am5p847dHN7jtngY/tEM9FxjZpiEFqMf9TVXYq+Mr30Nu08FYn hz8t2WPwqSKwvpDujMumnm0dZQ675AeCfIP4PL3RUb7EUigx5qAEqykM/LnU+t5c HHTVz8x7zMBn5gksCV4qlNQe2p++D2OfKYTdkamUMj9uLCygAYRVLzmoowNNjO3x MM8MVuQzgr7L0axiAJ5uM1bktv2BGGHQiigSXffEsAI3yzRsggL6Fneju0K4PYRq BLSWsdA4+HnC6z+O5tlIkvKKE8RrBRDe+9DdDKXVxbOQe0H6lyiQ== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44hhjttvkr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 03 Feb 2025 15:44:50 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 513FVq1I036259; Mon, 3 Feb 2025 15:44:49 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2047.outbound.protection.outlook.com [104.47.58.47]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 44j8fk1n63-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 03 Feb 2025 15:44:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=w9OVlPUcCnRv8bh50oyZ2PQeEtIKkbwyKu+umb6JylpauWo/j2VgQPPCOQLP4m58NLA4RkSsF+VC3vPDJL6FKbvZsq1z/s93N08mMODgoBVigAqK1smzR+e7afltP8emaZiRIteDY52hR8NnviUmcLV23L9jgQKZphA1/MxzUrd1/ZBwjJco7p3Hq0IyWVs1MJapnMvlW+L+rlxZtemFWaOK8LeCacdPo+SC1pGsP5XTmPNHa0CDyhiNDEDU1bfDPUppvCBei9y9Gi/PT9NUwFanjqbTPJxoN1t+utr3ohvxHTA2BRc8iHLW4R98YBF5FwSow75nOO/nJMWNMxNnbA== 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=vLg+yAyJ9yrlE2alTI++zuch7g5ozhWQTbKehwGTt50=; b=Vw54K2CZUuZFkAFfH95bfUvTje9nbhBL3IiC7X+UWcv2E8zPtC9NhP7++9BPNAaDCCdOGs6cqnn/ZpyIj+bhx3zUjn5u15HWmyZEDR7/u3PXd2x8fupnGfnQ7niFXuSkIpWn32vraHoOpY7lwVoyLBl+MJG57kRnFlx401NjR4LCPriWOxALJhJh+Pdu5xBlzjhkmWfYkghBqgSDGhMN7W05OfPGl8yAcVdnzRneHnqjWZY+G78uslWcuRkQDJSmVDX1DJ8ZEVoQ0qtqXCueK7nqLM4QovxOPPfD9z6aTnq/BNe3URuHEosov7w7HgCUuVvTxAZBRB9dnJcr8CldKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vLg+yAyJ9yrlE2alTI++zuch7g5ozhWQTbKehwGTt50=; b=hWTRKA4h6juRTHr75Vo17vLHiRTcPLVEl9n7oeJnjMix24aCq1pQo+2d++S4xqiS7yp4h1aUQtFlgukMLvW8zE16jLwefb04mrFd1SLVjm+ySagljTSz0HesOQJEwVZqk0xIz2g2Qm/tFE49FdQv62geg79I7gpLiKwzUnGWt9s= Received: from PH0PR10MB5777.namprd10.prod.outlook.com (2603:10b6:510:128::16) by DM6PR10MB4188.namprd10.prod.outlook.com (2603:10b6:5:21b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.25; Mon, 3 Feb 2025 15:44:46 +0000 Received: from PH0PR10MB5777.namprd10.prod.outlook.com ([fe80::75a8:21cc:f343:f68c]) by PH0PR10MB5777.namprd10.prod.outlook.com ([fe80::75a8:21cc:f343:f68c%4]) with mapi id 15.20.8398.025; Mon, 3 Feb 2025 15:44:46 +0000 Date: Mon, 3 Feb 2025 10:44:42 -0500 From: "Liam R. Howlett" To: Alice Ryhl Cc: Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH v13 2/8] mm: rust: add vm_area_struct methods that require read access Message-ID: Mail-Followup-To: "Liam R. Howlett" , Alice Ryhl , Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org References: <20250203-vma-v13-0-2b998268a396@google.com> <20250203-vma-v13-2-2b998268a396@google.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250203-vma-v13-2-2b998268a396@google.com> User-Agent: NeoMutt/20240425 X-ClientProxiedBy: YT4PR01CA0010.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:d1::17) To PH0PR10MB5777.namprd10.prod.outlook.com (2603:10b6:510:128::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR10MB5777:EE_|DM6PR10MB4188:EE_ X-MS-Office365-Filtering-Correlation-Id: 1f554dc5-1420-4c28-9597-08dd4469af6e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Jn9LL+B1Pa+eMx5CEaac6HaO70HArOAPzkqDLXpaxElHwNDBnKpNBd2Oic1M?= =?us-ascii?Q?eo/rZV60oL5/eOVq3O9iwncgDS3OY3Y3frnG6zNPJvZBJBwZOUqhF0DRRriN?= =?us-ascii?Q?+IO2DTaIpjafVM5CQVlwuLWrIz8HPX4TTnaBzUQgIVIhoa2CVhuwWwu5Thja?= =?us-ascii?Q?97UlErIj3XHZobZUXuVFHIA7yCzGCjXbyX1f68CZr7RKMlx9nD2hTtc8+DQ3?= =?us-ascii?Q?n0mnjc5uHWaiPiPLLWeKyYcDvgFEjfUiYB0jgIvluVKybztNBO0XkGxkbBjV?= =?us-ascii?Q?uQTqHc7Qgr5M8nUumsyyWE0t7GnjDJEKLH6RiqacfFenkuRiq6mCNjYEdMCL?= =?us-ascii?Q?AuZS7iy77z5fUaPBR3CibDEYJrLBzKGL+U0tbn2+x5edCwGmVOaqhLR9SoWY?= =?us-ascii?Q?KpsZOrsy/Z1G5t+SYlBckA8nOF5PpvVBLUdqk8gEiv5Kaap1uSnGdAabqy5n?= =?us-ascii?Q?LJ9lUb2FFls8l/OVvKNnf7fOjLlOVF0y0ALjFJzhukFGwGke/mSUe+8DBVRK?= =?us-ascii?Q?FHPwEBGneiDDUjuFc4jdVZTB78cVUgrubLh2osZeaJ+JsqyIWkH+iS76Lu43?= =?us-ascii?Q?8sjyJ2N8d06hDoCMTrqG4tO0DHp/42vgD3HPWpc9r3YsKvA+ccOOsRfZ7KKo?= =?us-ascii?Q?eY5t8lqEZv8LCURDjK6jGz+nWEO25PACa+FaO3n3AfdQs/wv3W5WOgLEzg6q?= =?us-ascii?Q?2oWuOfrTc+It1J8JoZEyIcm1DVpOuXTw+mjOu0R60ONklezLdMYlm4eSvepO?= =?us-ascii?Q?dcTPGlIZtTptg1FF7crUoNi5LT19YXGCRj2Hu0BU1+23hWoEdzPmASB98Xjo?= =?us-ascii?Q?xZJeG7CZ1o8epxHxdfgPN1lb8hY5S9m7bA3A7xIIaKySvr0C1P2T34vrup21?= =?us-ascii?Q?mmOVWSS9AAZhsPLj5Qg6FBSMainvqnqQlJasKDP54r5DYRhHTVFRYCjrrGma?= =?us-ascii?Q?ntvfhqA8dKHpDBgNJRBUdRSJzv5PK/Shqx4/aiYvUJCzkbnwFpfLjoolT3pv?= =?us-ascii?Q?vE1tf7gM1dZP9dyXT7Gd13QijUvsMn5AmuBKPlM5+BZ/bxVGV2d//YsZ+VK6?= =?us-ascii?Q?9t9/JNXsCZTS5X2a02ZoWct/oX1ruf5UL6VZibntmeULlFgVqMjSyPvAH63Q?= =?us-ascii?Q?YDXcZv/4WRbmwop9MX4m2TODsbT9u/iU37G5a8Hh+fCS+Wl/4KrPTKL837F1?= =?us-ascii?Q?w0NvxUyYJ4HPd+oiMLFAilA7eBjbYjcsCc1GbgGh694zgrcg9CY7wb7++dqE?= =?us-ascii?Q?SZNis1S0sQuUetk4rorV7gm2z4skFfB+0DmbaJ4t4aJzSsjTw9SETT5LmNWd?= =?us-ascii?Q?Ghog1FMRGeztYH6R5dAycPWpRt3q3dWK1gJy2IYFcB6Hm092GO5xPxynd+Wp?= =?us-ascii?Q?5lhxMuDY6E706WU81HwcyyIfiG3L?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR10MB5777.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7416014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?d6Zy1kad1pBeayHxr9j8/5YNtrxZY7NHu8AldqkTz76WG///KxuDCSr3X3F4?= =?us-ascii?Q?5OiD9A4FU0AjNUXfaiim8ep7TeqDWLwMZ6UVqnXhiZcL5b27/2JoVGNrkLyN?= =?us-ascii?Q?cuxPaclERf8aOZGHjWIlZ2/V9fy3YEc7voBZPbCyYy9H2pQdQvsnVLX862fA?= =?us-ascii?Q?ZkeclribTd0l2DNJkuYIeHUm38tCvCG2oAjCBzHwItsEGPwrvL8mfsmqTdyH?= =?us-ascii?Q?JF+h9rvKxZLHQS/cY807mp11Ow070/+Mp5FUDAYxf5l5rJub5TskaE3tMpol?= =?us-ascii?Q?IupAWcqMrEn+edY5H64mEYiF0XqtH2ZmzVkyjxb0C30pmom1PbFtzvVdyy4u?= =?us-ascii?Q?euS2/U+B3Iw/15W55/UaTccfvvMk3hOtt5+sPV+mciY6Kvfa37+sG23NxGKY?= =?us-ascii?Q?HbTXN0lstuPaxwuZ3mesAZqc9aEaj87Xe0oWRm86h+WovfH8le/lmB4n2Y0d?= =?us-ascii?Q?HqPdEdj8l3BadR0Hm2ExgUMbpPJsJtaHA1Us/wSqkPFmlKXf+wR2CDeCi4G6?= =?us-ascii?Q?AfxwnhUzLkK0s5SA5ztopvQHfvpQrzWHX78s1se7r90VuZigjmyQud3KLblF?= =?us-ascii?Q?xM1qSlQKeS3btNRYnZqZqubiCJjFGMLLTCn6rreVM0S/SdwKcEz+r6EuJGBk?= =?us-ascii?Q?SbMcNMnbLFABE8l+ujADwN5YTgANO8/YND4iexgM3GxHeVjGnb1yU3BzUR7Q?= =?us-ascii?Q?91Uzey0UyAJwPQETGHx7qsRcMl6ssGNqbFpsOYWYs/Qkc2WJp6vLGjtKqyNG?= =?us-ascii?Q?89lcTdDM8R6imk2jjxE7D/nw/nuDuFa8nOJsAL945ur94SxaTxcNKJKlJ/93?= =?us-ascii?Q?MIzdiJHhx4Z0BdeQ4DCKj3wKLPkcMC6I4LVxx7KoqwaDMQaleB/EVpKLWOYs?= =?us-ascii?Q?1wbYLr6rK4+h5OOUSxqeuQTYZMbp4gMzGDpaSgo+VCz52emdBa/KfYSNKNi0?= =?us-ascii?Q?eJi/RwwIS53qARf/hH98bFFosZ/YbY8Um3DveJ7wfB4GstHB7kc7BPEy5Dw6?= =?us-ascii?Q?hQ7K1LM+ULN+3eaHTWLat1VlNdtKyujjUxO/EwzOZupJNSw4NuKq2x9uCxdu?= =?us-ascii?Q?ujncbwOFAjHLY75ppdciurjcZ4sxo3o4zVxtHsNR+z7EFZiEeuMsvwmGJz59?= =?us-ascii?Q?7QYXoazX5v9UohManDlWvWwc7PZPORzVTpLeJ8XQg9mg4i8KBMnMmaqciura?= =?us-ascii?Q?Vg6hfUwQfEwICdSZHa1QhnlnD3sBbnXc9z+y5/C6U+gexIjXXDp8e1fG3YYV?= =?us-ascii?Q?vfD4tEPL1T9jM1l5+VK7d1WDmgzaTqDPx27OWfcVVtWKED33bPvfjSitMJP3?= =?us-ascii?Q?f0BOg3RtU/98ikKsgA1rYHz7AR6+8qFiT583Srw8EonLqFMf/7as8NYfa3yC?= =?us-ascii?Q?fzmpJFOQeGUA/xrH7p0b/N7bODZiAioa6EQ9szows0qucmTUCNTUbq1YyFwr?= =?us-ascii?Q?XVok73YEelpccsBmrzshrDNH6oStr+icmJUXdN+SQ2dxr4ZlKDib+OCNTruh?= =?us-ascii?Q?iTDZcbrN/uRuJGnVRW/qd8RqfkouRrU5XCcNalsEXaaoEfaJ8YjydadyI2uA?= =?us-ascii?Q?NmO+0GvQSL79JYmmZ2b/HQ1d0X7lqZQRlUlaNVQS?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: mSsm+nPEcBPh7kKNW88UpTBEBn7ajE2pBk/i2zg0G9GoUOgp7FvUZ4+nV6U2tplXQVzV2p4If7/VadXQSrvhNJWBi2McGK1A9IepOawPpftwuhCJnF4i5J/Hw+piENY59+NtV4dVm5ux0nNiZ7lKaEjxLDJjXT/oGf8cgRZ6/o7iLTL5skSZBdn73R3Ukl6POpp/X9pdY2DySyjrT6NskCtK8vjta4PSEWyHx6sKZjVJvIOkyT0MnfkmdISTdGObiWd3xrA/5mcho6X+2FEcshL1rZ+Lhj28fcd8sOQJWF7VrLaEbKCMJtFdqCX6XF4tUCZ04okMOkaGttqgonV/VVmoyOzy7+JgU0TdhDHUrLH1pktmod4qhCKsJOHVJxNKZIRPsWN0DU9+IOxyWMHyhaG36LtIOARTEGoBVbpBBL03xrcTC3e6W9m/19DJmSPGSgVJBiUMDnjy/bqYLPp6Jb2Q+OQSG2gZGKRyBZi7qfb0+b2EWSv9BaHU2x5hDuP3HSBgUD0LOCqNdf1vYlWjkmersAIwEH+a9WnR5Hk/wy+tjt/qlJI58ods2Ga1WcpoV1VG1Ldj64Y+q4M8TG99lFDtxRNTfM6FoaDBFuJCMs0= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f554dc5-1420-4c28-9597-08dd4469af6e X-MS-Exchange-CrossTenant-AuthSource: PH0PR10MB5777.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2025 15:44:46.4951 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pgmMnLvWlbwUxt4wlpEVt6jvK4iRlIke8kwTGLaFa2/W0xovmwo1dtK3pNQRdAe9/OzSkstExgnph4PSe+uQ7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4188 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-02-03_06,2025-01-31_02,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 phishscore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2501170000 definitions=main-2502030115 X-Proofpoint-GUID: VmtkOsfLvVz5cmwSAuRL1xbpECkVjl7_ X-Proofpoint-ORIG-GUID: VmtkOsfLvVz5cmwSAuRL1xbpECkVjl7_ X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 49B49C0002 X-Stat-Signature: 6b4eaxs5jb8qhzsmoyow7hoc7bu6mrro X-HE-Tag: 1738597507-928620 X-HE-Meta: U2FsdGVkX19JeW4aoji3gw/3huai+9mS25K0zRy1Gx9y6SzAsYW6BerR9coTytzbil2mGDi9iat2xH0IiJBEJtFVe/pZjPyTILdq8k6wv5BIv8Z5LUxGLgWD/Pl6IgT2dC0Q4VfgLA53i4vdp5jIJ9lZuWXME4iaInpEE3Jij2XhIbRaHfXsLOhyt6mbnNwI902umcwHlWUAq0SPyj2mJv7Gs6LeQqRroWmDyc9Xou6oxtuj1ySc+5mQTVWGFYe2W0MQrEq+0EjAFY2RBOmMC4adVGwYpXUm4ckl7TLMu67vELjglVGTI2fB9Q+Ero5aiLeg3iCblOXJpLSIsTMnRIr6RnpTjRfajNTAMa0wQTPepqRcVUs4Ky6ogyKQxX0rMRj+etbunOFc7p2C6txLPNKAruzShTheXWnn58SQ/cTj+vBMyB4JGkLgZ/sE4yrfIceLQavQ8cHygeXlNucKcrP1fQb01E5uKsYGWrFREglqikmA+oiAm9i4ZLq3gK04pwp6kQGp//E3YRl3dcjnBbDPyVBNuh9Kms7ViWVr6CTJ52ZOBBf6dXvcZtpOiTONzWiMa2r1LoKRf49RDP57GT81mrJIQSn9M2bcLGa2w0AddNgWXBzEqXk/dEhAwf4IIeCX7hAIQnC6OV6Guy5e3XukIpKTXVtzkvCuqnZkqPzevJWMGAjA3j40xEZOMaydQ3S1hljcEyive0dmHz/fkNYdtjLVN9MQCcDv33CRC0mHrzmgBa3XkccX27Uli92OG5wCb9GJsSc72iHzdKzANUmAlBuWU0rYHpFF8HLf/gplVNcbrexJqOKdicKePzlpKcHMWoKEjpJ5MyZonUjl8H5KMWorSoT+vROvURKU9xV4Ok5pRN3asdEtcU/yxKrwQl5pKsA2ZmUiqDAGYw66JUvN4UOCLuRF0rByKNMoJxcP40Fv684FZLkbRUBi5bc5AOGyYVDo8abYtfzY3d8 NH/FyPLw NX28L5J9yNzlLfaLTjUehpHGtg4waQriE/pYLqybCCGam6gPFgI4rJRBS8PbhTPdnBnTmLsWL6oyqdVmyJ9KDEEWlbk8/QNgs4qJFSrZejy5aOrVFyi/EYd+E7vtU17QDeV2W6uK09JO3P7W5bidE0N4pD+NzUC4ipSyEeaCF9B85P7lWhvkfaVXJfH3J6hUVvNV4sjt5IciK1y/vEFoHEEL0MEIyhaRQsJE6CXVelrANw8LUDrJ8TkLOJ7Plx0q3ppwWYSKHMjzvVXip3vkEdoH7WGjNmzEFHo2s3Ohjg+4L7Y+Z84QjeoWK2PhR1scn+RczTm2kPlbiCtOO73UNhayWdEoBLVrfagwUR+rwMClMxYaHquw3qw+kHJEDMwOTp0E0pWEEwWpBft4T8zUlmvBycXW1qFvg0tsk+f/n9C+YfAOLUuhe2mtjr9slIFYlRnd15UEoWehGlzrvoRDcDjxYturB467Nben8YbO9OQw/962OYhwqD58bWyFri0kA6icVrY88BuDHu8lQ4m0tbVmyxPE/HJsOttTSqeJOOsZJDBPvsZAOv8ObtM5xj2XhnpVslsfJPGk+7/v5ktbf5Oo4X+6ZxW+nvz9dlI4sB2EpguLs9C+AzwG7upTvp/VtKSBgyB4CgZIStwj1N7oZjXDDVIic3kiJSfA1msNfzeW2xx1OMJJviC7yYs9xytcJpbOhcG0+BJJDUaV4qYBYkGzZNaC99xrLtLmyferRBHqLlUY= X-Bogosity: Unsure, tests=bogofilter, spamicity=0.478136, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: * Alice Ryhl [250203 07:15]: Hi Alice, These comments are probably for my education. I'm holding back my training on naming and trying to reconcile the snake-case and upper case camel of the rust language. > This adds a type called VmAreaRef which is used when referencing a vma How did you land on VmAreaRef? Why not VmaRef? We mostly use vma for vmas today, not vm_area. Is it because the header declares it vm_area_struct? I'd be happier with VmaRef, but I'm guessing this is a direct translation from vm_area_struct? > that you have read access to. Here, read access means that you hold > either the mmap read lock or the vma read lock (or stronger). I have questions.. they are below. > > Additionally, a vma_lookup method is added to the mmap read guard, which > enables you to obtain a &VmAreaRef in safe Rust code. > > This patch only provides a way to lock the mmap read lock, but a > follow-up patch also provides a way to just lock the vma read lock. > > Acked-by: Lorenzo Stoakes > Reviewed-by: Jann Horn > Reviewed-by: Andreas Hindborg > Signed-off-by: Alice Ryhl > --- > rust/helpers/mm.c | 6 ++ > rust/kernel/mm.rs | 21 +++++ > rust/kernel/mm/virt.rs | 215 +++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 242 insertions(+) > > diff --git a/rust/helpers/mm.c b/rust/helpers/mm.c > index 7201747a5d31..7b72eb065a3e 100644 > --- a/rust/helpers/mm.c > +++ b/rust/helpers/mm.c > @@ -37,3 +37,9 @@ void rust_helper_mmap_read_unlock(struct mm_struct *mm) > { > mmap_read_unlock(mm); > } > + > +struct vm_area_struct *rust_helper_vma_lookup(struct mm_struct *mm, > + unsigned long addr) > +{ > + return vma_lookup(mm, addr); > +} > diff --git a/rust/kernel/mm.rs b/rust/kernel/mm.rs > index 2fb5f440af60..bd6ff40f106f 100644 > --- a/rust/kernel/mm.rs > +++ b/rust/kernel/mm.rs > @@ -17,6 +17,8 @@ > }; > use core::{ops::Deref, ptr::NonNull}; > > +pub mod virt; > + > /// A wrapper for the kernel's `struct mm_struct`. > /// > /// This represents the address space of a userspace process, so each process has one `Mm` > @@ -200,6 +202,25 @@ pub struct MmapReadGuard<'a> { > _nts: NotThreadSafe, > } > > +impl<'a> MmapReadGuard<'a> { > + /// Look up a vma at the given address. > + #[inline] > + pub fn vma_lookup(&self, vma_addr: usize) -> Option<&virt::VmAreaRef> { > + // SAFETY: We hold a reference to the mm, so the pointer must be valid. Any value is okay > + // for `vma_addr`. Is this true? In C we hold a reference to the mm and the vma can still go away. We get safety from the locking on the C side. > + let vma = unsafe { bindings::vma_lookup(self.mm.as_raw(), vma_addr) }; > + > + if vma.is_null() { > + None > + } else { > + // SAFETY: We just checked that a vma was found, so the pointer is valid. Furthermore, > + // the returned area will borrow from this read lock guard, so it can only be used > + // while the mmap read lock is still held. So We have complicated the locking of the vmas with rcu and per-vma locking recently. We are now able to look up and use a vma under the rcu read lock. Does this translate to rust model? I believe this is true in recent version of binder as well? > + unsafe { Some(virt::VmAreaRef::from_raw(vma)) } > + } > + } > +} > + > impl Drop for MmapReadGuard<'_> { > #[inline] > fn drop(&mut self) { > diff --git a/rust/kernel/mm/virt.rs b/rust/kernel/mm/virt.rs > new file mode 100644 > index 000000000000..dfe147cafdb3 > --- /dev/null > +++ b/rust/kernel/mm/virt.rs > @@ -0,0 +1,215 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +// Copyright (C) 2024 Google LLC. > + > +//! Virtual memory. > +//! > +//! This module deals with managing a single VMA in the address space of a userspace process. Each > +//! VMA corresponds to a region of memory that the userspace process can access, and the VMA lets > +//! you control what happens when userspace reads or writes to that region of memory. > +//! > +//! The module has several different Rust types that all correspond to the C type called > +//! `vm_area_struct`. The different structs represent what kind of access you have to the VMA, e.g. > +//! [`VmAreaRef`] is used when you hold the mmap or vma read lock. Using the appropriate struct > +//! ensures that you can't, for example, accidentally call a function that requires holding the > +//! write lock when you only hold the read lock. > + > +use crate::{bindings, mm::MmWithUser, types::Opaque}; > + > +/// A wrapper for the kernel's `struct vm_area_struct` with read access. > +/// > +/// It represents an area of virtual memory. > +/// > +/// # Invariants > +/// > +/// The caller must hold the mmap read lock or the vma read lock. > +#[repr(transparent)] > +pub struct VmAreaRef { > + vma: Opaque, > +} > + > +// Methods you can call when holding the mmap or vma read lock (or stronger). They must be usable > +// no matter what the vma flags are. > +impl VmAreaRef { > + /// Access a virtual memory area given a raw pointer. > + /// > + /// # Safety > + /// > + /// Callers must ensure that `vma` is valid for the duration of 'a, and that the mmap or vma > + /// read lock (or stronger) is held for at least the duration of 'a. What is 'a? > + #[inline] > + pub unsafe fn from_raw<'a>(vma: *const bindings::vm_area_struct) -> &'a Self { This 'a? What can I look up in rust to know what this is about? > + // SAFETY: The caller ensures that the invariants are satisfied for the duration of 'a. > + unsafe { &*vma.cast() } > + } > + > + /// Returns a raw pointer to this area. > + #[inline] > + pub fn as_ptr(&self) -> *mut bindings::vm_area_struct { > + self.vma.get() > + } > + > + /// Access the underlying `mm_struct`. > + #[inline] > + pub fn mm(&self) -> &MmWithUser { > + // SAFETY: By the type invariants, this `vm_area_struct` is valid and we hold the mmap/vma > + // read lock or stronger. This implies that the underlying mm has a non-zero value of > + // `mm_users`. Again, I'm not sure this statement still holds as it once did? > + unsafe { MmWithUser::from_raw((*self.as_ptr()).vm_mm) } > + } > + > + /// Returns the flags associated with the virtual memory area. > + /// > + /// The possible flags are a combination of the constants in [`flags`]. > + #[inline] > + pub fn flags(&self) -> vm_flags_t { > + // SAFETY: By the type invariants, the caller holds at least the mmap read lock, so this > + // access is not a data race. > + unsafe { (*self.as_ptr()).__bindgen_anon_2.vm_flags } > + } > + > + /// Returns the (inclusive) start address of the virtual memory area. > + #[inline] > + pub fn start(&self) -> usize { > + // SAFETY: By the type invariants, the caller holds at least the mmap read lock, so this > + // access is not a data race. > + unsafe { (*self.as_ptr()).__bindgen_anon_1.__bindgen_anon_1.vm_start } > + } > + > + /// Returns the (exclusive) end address of the virtual memory area. > + #[inline] > + pub fn end(&self) -> usize { > + // SAFETY: By the type invariants, the caller holds at least the mmap read lock, so this > + // access is not a data race. > + unsafe { (*self.as_ptr()).__bindgen_anon_1.__bindgen_anon_1.vm_end } > + } > + > + /// Zap pages in the given page range. > + /// > + /// This clears page table mappings for the range at the leaf level, leaving all other page > + /// tables intact, and freeing any memory referenced by the VMA in this range. That is, > + /// anonymous memory is completely freed, file-backed memory has its reference count on page > + /// cache folio's dropped, any dirty data will still be written back to disk as usual. > + /// > + /// It may seem odd that we clear at the leaf level, this is however a product of the page > + /// table structure used to map physical memory into a virtual address space - each virtual > + /// address actually consists of a bitmap of array indices into page tables, which form a > + /// hierarchical page table level structure. > + /// > + /// As a result, each page table level maps a multiple of page table levels below, and thus > + /// span ever increasing ranges of pages. At the leaf or PTE level, we map the actual physical > + /// memory. > + /// > + /// It is here where a zap operates, as it the only place we can be certain of clearing without > + /// impacting any other virtual mappings. It is an implementation detail as to whether the > + /// kernel goes further in freeing unused page tables, but for the purposes of this operation > + /// we must only assume that the leaf level is cleared. > + #[inline] > + pub fn zap_page_range_single(&self, address: usize, size: usize) { > + let (end, did_overflow) = address.overflowing_add(size); > + if did_overflow || address < self.start() || self.end() < end { > + // TODO: call WARN_ONCE once Rust version of it is added > + return; > + } > + > + // SAFETY: By the type invariants, the caller has read access to this VMA, which is > + // sufficient for this method call. This method has no requirements on the vma flags. The > + // address range is checked to be within the vma. > + unsafe { > + bindings::zap_page_range_single( > + self.as_ptr(), > + address, > + size, > + core::ptr::null_mut(), > + ) > + }; > + } > +} > + > +/// The integer type used for vma flags. > +#[doc(inline)] > +pub use bindings::vm_flags_t; > + > +/// All possible flags for [`VmAreaRef`]. > +pub mod flags { > + use super::vm_flags_t; > + use crate::bindings; > + > + /// No flags are set. > + pub const NONE: vm_flags_t = bindings::VM_NONE as _; > + > + /// Mapping allows reads. > + pub const READ: vm_flags_t = bindings::VM_READ as _; > + > + /// Mapping allows writes. > + pub const WRITE: vm_flags_t = bindings::VM_WRITE as _; > + > + /// Mapping allows execution. > + pub const EXEC: vm_flags_t = bindings::VM_EXEC as _; > + > + /// Mapping is shared. > + pub const SHARED: vm_flags_t = bindings::VM_SHARED as _; > + > + /// Mapping may be updated to allow reads. > + pub const MAYREAD: vm_flags_t = bindings::VM_MAYREAD as _; > + > + /// Mapping may be updated to allow writes. > + pub const MAYWRITE: vm_flags_t = bindings::VM_MAYWRITE as _; > + > + /// Mapping may be updated to allow execution. > + pub const MAYEXEC: vm_flags_t = bindings::VM_MAYEXEC as _; > + > + /// Mapping may be updated to be shared. > + pub const MAYSHARE: vm_flags_t = bindings::VM_MAYSHARE as _; > + > + /// Page-ranges managed without `struct page`, just pure PFN. > + pub const PFNMAP: vm_flags_t = bindings::VM_PFNMAP as _; > + > + /// Memory mapped I/O or similar. > + pub const IO: vm_flags_t = bindings::VM_IO as _; > + > + /// Do not copy this vma on fork. > + pub const DONTCOPY: vm_flags_t = bindings::VM_DONTCOPY as _; > + > + /// Cannot expand with mremap(). > + pub const DONTEXPAND: vm_flags_t = bindings::VM_DONTEXPAND as _; > + > + /// Lock the pages covered when they are faulted in. > + pub const LOCKONFAULT: vm_flags_t = bindings::VM_LOCKONFAULT as _; > + > + /// Is a VM accounted object. > + pub const ACCOUNT: vm_flags_t = bindings::VM_ACCOUNT as _; > + > + /// Should the VM suppress accounting. > + pub const NORESERVE: vm_flags_t = bindings::VM_NORESERVE as _; > + > + /// Huge TLB Page VM. > + pub const HUGETLB: vm_flags_t = bindings::VM_HUGETLB as _; > + > + /// Synchronous page faults. (DAX-specific) > + pub const SYNC: vm_flags_t = bindings::VM_SYNC as _; > + > + /// Architecture-specific flag. > + pub const ARCH_1: vm_flags_t = bindings::VM_ARCH_1 as _; > + > + /// Wipe VMA contents in child on fork. > + pub const WIPEONFORK: vm_flags_t = bindings::VM_WIPEONFORK as _; > + > + /// Do not include in the core dump. > + pub const DONTDUMP: vm_flags_t = bindings::VM_DONTDUMP as _; > + > + /// Not soft dirty clean area. > + pub const SOFTDIRTY: vm_flags_t = bindings::VM_SOFTDIRTY as _; > + > + /// Can contain `struct page` and pure PFN pages. > + pub const MIXEDMAP: vm_flags_t = bindings::VM_MIXEDMAP as _; > + > + /// MADV_HUGEPAGE marked this vma. > + pub const HUGEPAGE: vm_flags_t = bindings::VM_HUGEPAGE as _; > + > + /// MADV_NOHUGEPAGE marked this vma. > + pub const NOHUGEPAGE: vm_flags_t = bindings::VM_NOHUGEPAGE as _; > + > + /// KSM may merge identical pages. > + pub const MERGEABLE: vm_flags_t = bindings::VM_MERGEABLE as _; > +} > > -- > 2.48.1.362.g079036d154-goog >