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 51371C0218B for ; Fri, 24 Jan 2025 19:09:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D37436B00B4; Fri, 24 Jan 2025 14:09:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC124280065; Fri, 24 Jan 2025 14:09:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC5546B00B6; Fri, 24 Jan 2025 14:09:40 -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 828896B00B4 for ; Fri, 24 Jan 2025 14:09:40 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 09A674B474 for ; Fri, 24 Jan 2025 19:09:40 +0000 (UTC) X-FDA: 83043284520.20.5A231E1 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf09.hostedemail.com (Postfix) with ESMTP id 91CEB14000F for ; Fri, 24 Jan 2025 19:09:36 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=iBDi7SQe; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=YWovNWZY; spf=pass (imf09.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737745776; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5EY0Ay2647EC7h7wvLoHnlFu7HdxH0YBkooAOhjLW4o=; b=YSAgGd8nZGDerUjgGkhT+yKx72zgeRgTBbRsv9IA5+PZ2+N3av7lCPB4psGsI3IWiozTL/ Uhx3d+5RO1a/5CctHfA5x6QBixgZK/Np7WvpQ9AIuOSlyOF61vOLD0KN41r1mlcBydxLtc Mwpbx9MxqzoUV9jgNxhTOkmcrjUTllE= ARC-Authentication-Results: i=2; imf09.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=iBDi7SQe; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=YWovNWZY; spf=pass (imf09.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1737745776; a=rsa-sha256; cv=pass; b=r+fH/BPzE7SgV+zTrPFaqWm7lcUhBZQIJpZ2EcDEkDRRyyhCjFDtsG9FkSg4cHCcK7UGY0 HpgOL7b4wt30SxQD0EMOmsoFWN9YGTOUqQJR1sL7Wz1B/xEV7AlwgCYwL0j4dSVBp9wM01 jQDSPZJiZWs8liPzoVce8dEt7fhRabs= Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50OINNHR019388; Fri, 24 Jan 2025 19:09:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=corp-2023-11-20; bh=5EY0Ay2647EC7h7wvL oHnlFu7HdxH0YBkooAOhjLW4o=; b=iBDi7SQecrFSmI5CZny97eZ3zYdqkUqzyC o/Zi8jBcm/jgZekI9rOkhx/dG+C3oCxyYP3G1jSjiPwtkJ0vdckk9usZj9NlsyzW FB3xbIITlj5PQOE+b4VPbxDSxPO7Y3Ed3msm3sbt3zZ3ZHy+oOfmkTZWMzXmu3+8 BME3XW5dH3pxSqzGj2X8YNwn/ua0Hfki4A16JT7lL8n7apYZszqsrD+jINhA7wyB kfl/HEY3a6MW22QadayjB+z3B+oWmMcOaPzTn2bkO71ABEfNA7mRxq5xmExV1aW3 vQCIvL8HTk5zWj1JcLjHXwtr0gDAuTvdSO86kZNSQ6Fc+Hc+vwTQ== Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4485qavp3e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Jan 2025 19:09:20 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 50OHOiw9036496; Fri, 24 Jan 2025 19:09:19 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 44917tv8u8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Jan 2025 19:09:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HETy4TxsLO3GEGsOpNxgDnc4lK5cxioBthIJyeQtBnQ71l9y5ckN+v+gpDzB4RLVUD0ZSzqQUYqA7fQ45CMUkwQQYlhI/X4Md9HKpDDWEduU+qqZXVBVeaTv/mSYZISfp2QM+EvvVhLpBCp62Pxe1aVMrfBSW9OH1b2k/NurZlHMAqE2A0JMIvVr1DP3uD+uFiyBf5zIy0F/otJnXQqJwvEHzIeLVrhdoFgE0NqGpPnUQcKuf6kI4QxoYpE2sfb6AvHW6xmUlgr0/OhM7S3TbeyzKZbT+d/Wv0QYAGNQstDGrag6is+zFpCPUItOTDcq9UIxPx+UPReiF1EhjMDRhg== 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=5EY0Ay2647EC7h7wvLoHnlFu7HdxH0YBkooAOhjLW4o=; b=oxHwHYgh488fGl+Ll0kFIqTpAIQmhESz2OVEcu4E8t0Sxeb2NOfpbZQqyoUTLgkjtYwP9ywV3XTs+VFpR7zXFVrSVZ10E5nyc7sTpVxIUceiiqj8zUsNQIf+OngGVUV+xvODzbH/ogxIZSM85aMmlJZ6q/jJWXccMHaaZvGi6vA05B9mvmX1ZK4IjKFzmyU/9Tvi3flXlTD+iCOBM0xesk0awAI65PzxL49RvWfL6SIvoNd/MVodixxcvyhmQF+7J9bGbYbkt22u0xNl20saucyqvodqNWGBFx2FsIkyvr2k4fAbyIpBU3V928ClJmaf+ZfEdgafCahDEz23mNiG4w== 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=5EY0Ay2647EC7h7wvLoHnlFu7HdxH0YBkooAOhjLW4o=; b=YWovNWZYwhKUh2xaoLMe2jKgcknrLIGxHc1Bxt1+1kx8vIEKt6a6kaRvnTEczlmJqiK9Rm8JGVBbd1QYcMgWP+ein9McK6CCmcAzoHUaqrSCjewIKDKHKp6vRa/6mLJo3zmER1SGP/SLxax74Ioi5+cnyT7/4IieR0aU1UZEiqM= Received: from MN2PR10MB3374.namprd10.prod.outlook.com (2603:10b6:208:12b::29) by DS7PR10MB4910.namprd10.prod.outlook.com (2603:10b6:5:3a4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.17; Fri, 24 Jan 2025 19:09:17 +0000 Received: from MN2PR10MB3374.namprd10.prod.outlook.com ([fe80::eab5:3c8c:1b35:4348]) by MN2PR10MB3374.namprd10.prod.outlook.com ([fe80::eab5:3c8c:1b35:4348%3]) with mapi id 15.20.8377.009; Fri, 24 Jan 2025 19:09:17 +0000 Date: Fri, 24 Jan 2025 19:09:14 +0000 From: Lorenzo Stoakes To: "Liam R. Howlett" , Andrew Morton , maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jann Horn , Peter Zijlstra , Michal Hocko , Peng Zhang , Oleg Nesterov Subject: Re: [PATCH] kernel/fork: Be more careful about dup_mmap() failures Message-ID: <2a9fee95-425d-4b27-8253-10540669d94c@lucifer.local> References: <7a16bf18-e193-4e0a-9e3b-83f609cb9e72@lucifer.local> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO4P123CA0113.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::10) To MN2PR10MB3374.namprd10.prod.outlook.com (2603:10b6:208:12b::29) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR10MB3374:EE_|DS7PR10MB4910:EE_ X-MS-Office365-Filtering-Correlation-Id: f145699c-19a4-4d56-c536-08dd3caa9929 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|921020; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Jz/dRq4YfjceQGw+xtAW7VbjxwV9guMJs7KPyqeaUdN47ag1n5H55ZCYgwrg?= =?us-ascii?Q?C5ZnaTQ8R2lbwQ91PP4PlUBWshj+y3HyLqLodmPW4y09jT++fPYwDT6UVFz5?= =?us-ascii?Q?LIyWyro8fshswhW2C4ECEGfpT4yw1IPd5JFNxSdDPEP9tsX4daG3aEhSoQKR?= =?us-ascii?Q?m0qnKRLnGRSCLYwJXHGtGZ1Q6sQQFIJvZzTa+bx3gqYr/J3CpfQxUzUYmqpp?= =?us-ascii?Q?AKslMHJWPErNfwjCvVhGs5cI7E0JEQa5FD0U5AI1xiWS1qwOtwsdeR/o+Uai?= =?us-ascii?Q?wd52ZqnNSOol/8sNLpfPm/8PBiONhPRyKPfy55djEUoHBJGZ/Uxu5z21EQYy?= =?us-ascii?Q?ctLfp38k/B5cDzUHIEV4wkW3bkc/BtrfIC72RhovIV1AZwUSUiQUP9HMkvCj?= =?us-ascii?Q?rUxLvzIZSBMAsFGU+AWDCZr9Y0X3WTA+kCYIIgvwJ1AxiZyZ+cGv7XBkQBAQ?= =?us-ascii?Q?ccS5Wax/B5zTfMlU0T7nmvha1OABbhisbhN3/9rFKJBTcbhroZXhBych7/jA?= =?us-ascii?Q?BrcSIwNu0aDqkSZiVz0hp/4+Yc9wtqvgpXQhyM4rBS7hXnFdftUjL13+rfAN?= =?us-ascii?Q?uKxNpfsQMDGC9H6W4Qze+Lc/3jh/Bs9vwmwVwAVnhJUh0+Rg55sFjm+8OfZv?= =?us-ascii?Q?081ZgaEP9115ZGqJTLoK23p8UQcyQyW2zdXdN/FD9Jcs7mmTR5GKS2f+tj+R?= =?us-ascii?Q?ogY6tV36R+mzR+c+IF9+W+/FvDQkvon79TKOYPKbR/H4UC5gaiZTNBq3gtfy?= =?us-ascii?Q?xtJ9Yw8jpq13pi5fA3s7gjTrLGIxP/9/R+/IUaU8C643f/Kmp1TmKB3hmayt?= =?us-ascii?Q?BngW+B2hMD1susZY3BJiXPNVcw4VIDpmdSEJIIDbF2OqakZFVUBI4H4fuCpN?= =?us-ascii?Q?iYuiKgk+cx1PcH6ZwOQuy+a1iEmQMwlFoiAPg7lyxVXHBXSuN+vtO+56b6j4?= =?us-ascii?Q?65TXczSCEL4DwCu13hV6g6H7dnjhxJg+J1dQxpPK8bWXEUzYQgwpXiwjuSz+?= =?us-ascii?Q?fo4zSUuMioXGHC2aJwe7uKhUKBzBNl24S1r+NmD9Nvd0995V4sS7mhQrM1Em?= =?us-ascii?Q?G3/7se1dCeN7Zt+TcNVZqowOBjHyUNB5HsgJ+cIE4aRepxtdfdd9117chMrR?= =?us-ascii?Q?tbG/z6597J/KF8YViUea5tWZCUrD438s/zNa4hbCR+6lGIYGQN27/qCdegx9?= =?us-ascii?Q?SZNua+/XulQuP9rZ8k5IrtjyM5PVySvnEQ6YivDQTEOYwDqxWROx9jHadwgv?= =?us-ascii?Q?HW6D3dXgiBgesOoas9lSaNvShpSPRfPhUWaut4hsoi8o8aSt9qgUNXetXVvu?= =?us-ascii?Q?ToFvykOP/8Lc9AkpkXPon+yysO0N4kVgEIXwgI+6YOZ3kPbdIXshD6jnyWBZ?= =?us-ascii?Q?xsiWSD1mvt+g7y/jlxpoKlYV+hzAvi0JLfTRou1HaamWNX6NB79vo5itrXqV?= =?us-ascii?Q?0I1x5d37guMP8Ya90kWWdxKIrkOkUxAn?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR10MB3374.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(921020);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?m8KJ9TaZONfUioCxhtMldhQh9976vSTCQ0vZHnL3x5OslJHkm5cvqOCgO7dz?= =?us-ascii?Q?kt1UW9y1NZOYq+yj3sSkdtn5hzRzYUZhPWPLwuaar8pzRY70zT7yyIaXbsQ9?= =?us-ascii?Q?F/vh7M/7gx91yMSZeBnudWUv31s+rn2JvnPVO/AfdbudNR48jkczqNYNPF0w?= =?us-ascii?Q?LUt6encZZ/aYOatVjt0AGDocZfMAFk88rMHzCDOmxrkI6ns9REhN0GkKRJ1/?= =?us-ascii?Q?lL90nUpHjqz+lXVkOGUfGat9Z0GEYcKglFrtyHt4k2dJ2Vapfb84HOEJXzgL?= =?us-ascii?Q?CL45rWMlz5MXBd43/gqHhE80lLd+h3sutERjsSULCgfGNmxy1MCkiYYnZPqi?= =?us-ascii?Q?ALfLxWQmK8rqh/GviYiH1Au1gwNkui2kcKLk8ui0VtwZx/hM6fsoZ5ezhk3u?= =?us-ascii?Q?9Vde+Z0LJta2R5bJELlwdtvZzMeb1S1a86qYlfUrqAuxWpEs+eWW5CcKxZ4n?= =?us-ascii?Q?BVlcVflb6mPvMjK/HaQ/yP6uVk8HU5NbKzBng56LvTa+XT7r50mOGLWwaxcj?= =?us-ascii?Q?4fW0SSZIDXecrUnDEaRFCrPYIrazwzDp5OXa/DtJ/6owCg0VVqwJwKjaZh83?= =?us-ascii?Q?qdxuQbSIi7z8Jku9LbEPJfv4uJNO3mM+CbtwIGqZNomFrT0u+WK+OclHeNI9?= =?us-ascii?Q?BESJwLEXuhVPOpLPEc+sKk9SVkI/XYaEOs+USkf4VOO1/DoijzohndX0jdqy?= =?us-ascii?Q?xmago7AcFiRcDUlFkGH85o0xV37vt9OfkdXENXHgPmlDM9ljBtlgbLN3PU2Z?= =?us-ascii?Q?OeL/K9T+cahTJDysatdZ0YO0g4jOsKun3zoptwUdzlNprIh3gb8oW1+ZFhPS?= =?us-ascii?Q?FpmOawEsLBuv5NJvliEIAxsaxR5k4nZZF3Tke8TsGDTaaHY7KafxIWCeUHDs?= =?us-ascii?Q?aE4UfT+3SafG5wnh6Ks01h0km1aMhwf0EfzjEaD1lr0jJCzVyDDj/cabBY15?= =?us-ascii?Q?TKlFHsWCAtytI2IVdoos+O3Zwwh9NaSoHprFCBJqUPmbizzcsxPqUbYiMBd+?= =?us-ascii?Q?4yfwJdU6UnuUVhg6BhE+6Xm3Fib1IelGGYZj84vKKpdBMLt8b3ur429TMnM8?= =?us-ascii?Q?/w0O5tlJFTBSmFaM40ZuJ3TiepTDOMaaArPK323y/Mn3WjzpUIMRoNqpxSYv?= =?us-ascii?Q?T2/7K2KchmQ680VK4+3W/ggaxEctyEX/D0h3WS088KX3wTLQ2qIPk5PZPccr?= =?us-ascii?Q?WkDdHEBIFRXhRzXU/b4pEdOec4SZIixWIqZ0IE6KceIWogDvwQkK1ksSu7Ia?= =?us-ascii?Q?keQjbZ6Rh1svIeG3wX1V46HiP3TmvWs/kOj89EPXY9Mw9s6i7NLYAuVlnKiT?= =?us-ascii?Q?kbt89498SgWN6xym35OyLktCSoV1Jvh2MBXdWAdgeBDEYPqqrrbqOqv1rS6V?= =?us-ascii?Q?veJbUVM0PzEVm/thhwCSEj+jiTiJHZw4CAUIfJtWFAKtLf4U4tEVRdfilIFs?= =?us-ascii?Q?Lf+Q9uKUeSxw3Lu2jcsLTNFD9n0erBgamWOquhqLOqUCt9PguPOUdJIYSzk+?= =?us-ascii?Q?aqGMovfg99CGR0esdhQGpv+QmKg+82hdMdNKYwhLm6eJRZiuro6grqz9nHgx?= =?us-ascii?Q?T+0bPHn9S/T0oouSpqB7rm5nwI6WQ7ysQixxBDz4LiUS0Ml+J/S6x94jR1vr?= =?us-ascii?Q?jw=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 1g8guSZUFVapBCNhCEaqFbo/ZUv6wVCpy9MA9xD1xwRhSEFbqERx3TtyC0hzgT+BNCSmYUzNbY67Uei/RZn4VHSdEY9ac6ZYni9qBAkRFMt6rwCD3ZE11Gwu/shxU7pQvbfmW13XpD0ZC+79b03estI7wNv2uPFN13AciWTFe5fPBakUTUnRo9ySFDbUFQeYlecotlebccpGj6yrLRRPTRX1ASFJ3EqJRm9z1zmg6n3SU0ZhkX21d4iOw3G49JjlEIkpYO1EL8DFD51OAXN94+y0fEbdd52QQaV3XtJWvOeoNzqf3OUZeJpWCNOZbs2kEYUzOV0QOoQMZcEFBbkXo09bOCScc0Q3I5W5cs5P3b1Xbb26ZHOgceqgDj5WqLFodIKJOf2X9j9DnBgLUQBvFJ93FZYtcg1pie4WAXAfVln+cvdrmq0nw+vM59qAuE29mNujXBodOaI4AO1gNP20f7KXxpqkEXmqYGYML5knWE0AQ/K5Fk9750IcE+EdqiuAllHgICCD+jML63kLIsw8hYCDeLiYI0Qqe6atYo8iSbY9PntwF6Qn3CCVye2YmUouNyftlUp78ooJpb9AvVrMMFtGkHMx3Tn0Zpm9kL9ZgCg= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: f145699c-19a4-4d56-c536-08dd3caa9929 X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3374.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2025 19:09:17.0122 (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: uZNNx4rCJErNLDYjLOQAZnwlD/jikuu0qTtbsnladnjb5u40Mcr7Fg+ujuKUqIt9z3MzlP+OEG/HLv6qAhpUC5JBw7s0Zde3vw6DgirB0N8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB4910 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-01-24_08,2025-01-23_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501240131 X-Proofpoint-GUID: iQeZ3LWmhCqCwUT-swKwOh-ltZHSYckP X-Proofpoint-ORIG-GUID: iQeZ3LWmhCqCwUT-swKwOh-ltZHSYckP X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 91CEB14000F X-Stat-Signature: 6973h5oon9tofz6qh5xcne37wiz1sfn8 X-Rspam-User: X-HE-Tag: 1737745776-421746 X-HE-Meta: U2FsdGVkX19mQgTCM5KDsjqax+4IDnu4i2fnOqy9Q4eUOkRN/nWEdeTaaY6YOFftbEH82z7AqF9YhsjVaZN984R6KXdZ/iL/MPfL4AeGaWGYkf96VlYYhHvhrf7hf4vhAbTZGmqqVJ28N54RgSdeae1KrMeyGf1BAT2bKak+VULy6htjgzrIq99wSIao/aKqOl4tOHTm8rX5DASOPJltZAzfnMQkXSaaUx+ge6EiLiefSQqfELmz3QF2HdOOTV4j84/zGZ1VtTmymbOPCdgHtPR3+jmUJl40v+qKHrKfT+UmHesVMNlIEPBAhbKqaC5bH7P4rvn5jY2uUdKShfuGcykp4sXrtKELxcv1DLHiCSrV0ewvunMBdrLgBEW5gGWIZe7jcCwkrxew5fZKE+4ny6c23ZD8k0zjooBp9dyWfEQOCyTHTCllOyrhiOoGUkSxVRoOgcrrhxE05L+xzd0kohKGiePzP5JA5yJXrCCDuDVuQxmeKwJkJToH1Vcda+7D0pyCyBH7FT4ItH31M8GOTGJaDebfdpvfhqi3oZx5JcakpdKQWTnPqdPKaqNpo4yFGW1Ux+8ebuK7QSaBlLA+O4PZU7rvH2vXm74pBpAbf4ND9oiEC2Pkc2yKn28prMSyRxKYSyZDP0TQYkWhLLqB7CYFCogmBAlHesFk0Hf7zMpCB3R110kImTfp4LaBMNj6IufaDedS4xuQrwbG0gFAOu5nFBW5T5UdAUglh3zCkKDwqVJXc+rhoCei+D2l8r6J1LZd1RbPm9tSJAL1VKVkT/1aWS6WajYq29KkD2s70uL2L68DvugaWSSIZlUom+61ILb7N0J2Vy7Cg9IyD2ScFOite0ZiX3pMOUjYVkVIh3yzSSvKhjUfn5oVdDTMmkKctZfqQ8Uqj8rrRly6XQcH2izZ2v+jUMYcQ+hSdFst+H2H6WumbQ+ZAa2hcI+0aE58k0GISuUwk8rsw+6edEL ap1/S7VA LwFd7OEyDAsDknLw/LuB2uRe0i0GolKDDBRK64lUa3zmEdcBBSmtHu9LxybA8Mx9qFo3kQS1POaMZgAQ7azkw6pvR9rualFFtdlYI5B0iSzrpaJvbrCvH7TUWCsSazxu7WZNyQLe+mBQIPwyd84LNfZQECQmqsR157aTQrvQk4c3G7NlrQYt1WrEIfJ55ggqjBsJj+pFDbxJaAhHJ/gINHW7i6ODn1ubQRWxtsd+lkqR2dbHMGpPS2QPvHtKruU7yiv0Oczq4R7vgUnlu16wc19IdvMH7X//vtEm27HVohQr9JLnGrYUhjYChbuPfejLOZsOHGE8jZvg6PQNT/XiuAkgs4dNWHquJWINiBNQO4T7M0UgP/TYLXQh6PUVxsAXvfFi7ZEe2bFtfhyD66T/s1OmV2q/HlNFE606jcU06gbD3NFZEYIF3QrqeO32Wcn+b3Z+eaHrRLGASMYA3l6I3dx8o4Oct8UGfag566W2WYqT4o+zY2PiLO8TqZ/Lm4dfolKviALg4fFmgWnKuhQ1g34/kbOILCt15oT+5NKaUJgbWNXI0GweEHu7tFirsLNAZMxT/0MgPiONX4CfiPjDqIiwh9w/L+0B2YKd5JmessqbjuJW2/RdR6vp3jnO7gj5maORi4sJJiePxUI1PdAdrVR9ptxeSQRGNLOGuYAqa08D/yiAnVAVGZvmSOyQd20Fd8JpZCLrw6VIs9OeaCVa6L6B6cq0DhoKM+L+4grN9sKhwCFngk2LM3WyZ4h27emEH7JW5+v0KV270aS0xFDQQBVjM52rJfc9g5YyZiRPJ3X3eguw= 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 Fri, Jan 24, 2025 at 01:19:45PM -0500, Liam R. Howlett wrote: > Adding Oleg, who I forgot on the start of this patch.. > > > * Lorenzo Stoakes [250124 06:15]: > > On Thu, Jan 23, 2025 at 03:58:49PM -0500, Liam R. Howlett wrote: > > > From: "Liam R. Howlett" > > > > > > In the even that there is a failure during dup_mmap(), the maple tree > > > can be left in an unsafe state for other iterators besides the exit > > > path. > > > > > > The unsafe state is created after the tree is cloned, but before the > > > vmas are replaced; if a vma allocation fails (for instance), then the > > > tree will have a marker (XA_ZERO_ENTRY) to denote where to stop > > > destroying vmas on the exit path. This marker replaces a vma in the > > > tree and may be treated as a pointer to a vma in iterators besides the > > > special case exit_mmap() iterator. > > > > Thanks for addresing this. > > Thanks for looking at the patch. > > > > > In the original issue, the problem arose in vm_area_dup() which I tracked > > down to vma_iter_load() -> mas_walk() (see [0]). > > > > I'm not sure if your change would actually have addressed this? Would the > > MMF_UNSTABLE flag prevent this code path from being taken (if so where?), > > if not don't we need to add a check for this somewhere? > > > > [0]:https://lore.kernel.org/all/aa2c1930-becc-4bc5-adfb-96e88290acc7@lucifer.local/ > > Remote vma accesses use check_stable_address_space() to avoid races > with the oom killer, which checks MMF_UNSTABLE. > > Yeah, uprobe needs to do this and doesn't today. > > Oleg suggested this be done in build_map_info(), but the MMF_UNSTABLE > bit is set under the mmap read lock and that function uses the read lock > on the rmap, takes an mm references and records the address - then > revisits the mm later to get the vma in register_for_each_vma(). > > I think we need to check in register_for_each_vma(), prior to looking up > the vma. This way we hold the write lock on the mm and will ensure the > vma is stable from both the fork setup and a potential OOM events. The > concern is that we have an invalid vma or the prev/next is invalid and > that will only be a concern when operating on the vma itself, so this > would be the safest place imo. > > The problem that has been created is that the next vma may be invalid. > This arises when the rmap is used to find a vma then changes that vma. > In this scenario, the mmap lock of the vma needs to be held and that mm > needs to be checked as stable/not oom'ed. So we can limit the checking > of the code to the scenario where another mm's vma is found and > modified - which may cause a merge and look at the next vma. > > I haven't found anywhere else that looks up another mm_struct's vma and > makes a change to the vma. Considering what that would mean, it makes > sense that this is rare. > > So, I'll just do this: > > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -1260,6 +1260,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new) > * returns NULL in find_active_uprobe_rcu(). > */ > mmap_write_lock(mm); > + if (check_stable_address_space(mm) > + goto unlock; > + > > Yeah I think on reflection this is sensible, at least as a proximate solution. It certainly doesn't harm to apply the MMF_UNSTABLE flag on top of this and we can always expand where we check/what we do with this. > > > > > > > > > > All the locks are dropped before the exit_mmap() call, but the > > > incomplete mm_struct can be reached through (at least) the rmap finding > > > the vmas which have a pointer back to the mm_struct. > > > > > > Up to this point, there have been no issues with being able to find an > > > mm_sturct that was only partially initialised. Syzbot was able to make > > > the incomplete mm_struct fail with recent forking changes, so it has > > > been proven unsafe to use the mm_sturct that hasn't been initialised, as > > > referenced in the link below. > > > > > > Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to > > > invalid mm") fixed the uprobe access, it does not completely remove the > > > race. > > > > > > This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on > > > the oom side (even though this is extremely unlikely to be selected as > > > an oom victim in the race window), and sets MMF_UNSTABLE to avoid other > > > potential users from using a partially initialised mm_struct. > > > > Good to have it set also I think. > > > > We were concerned that _somehow_ MMF_UNSTABLE might cause some issue in > > OOM, which was why when I first thought of this we decided maybe not just > > to be safe, but I am confident this will not be an issue as indicating that > > something is about to be torn down and is unstable when it is in fact > > unstable and about to be torn down is correct, plus I checked all the paths > > where this impacted and found no issues. > > > > And in any case, setting this flag avoids the problem...! > > > > > > > > Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE@google.com/ > > > Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") > > > Cc: Jann Horn > > > Cc: Lorenzo Stoakes > > > Cc: Peter Zijlstra > > > Cc: Michal Hocko > > > Cc: Peng Zhang > > > Signed-off-by: Liam R. Howlett > > > --- > > > kernel/fork.c | 17 ++++++++++++++--- > > > 1 file changed, 14 insertions(+), 3 deletions(-) > > > > > > diff --git a/kernel/fork.c b/kernel/fork.c > > > index ded49f18cd95c..20b2120f019ca 100644 > > > --- a/kernel/fork.c > > > +++ b/kernel/fork.c > > > @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, > > > mt_set_in_rcu(vmi.mas.tree); > > > ksm_fork(mm, oldmm); > > > khugepaged_fork(mm, oldmm); > > > - } else if (mpnt) { > > > + } else { > > > + > > > /* > > > * The entire maple tree has already been duplicated. If the > > > * mmap duplication fails, mark the failure point with > > > @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, > > > * stop releasing VMAs that have not been duplicated after this > > > * point. > > > */ > > > - mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1); > > > - mas_store(&vmi.mas, XA_ZERO_ENTRY); > > > + if (mpnt) { > > > + mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1); > > > + mas_store(&vmi.mas, XA_ZERO_ENTRY); > > > + /* Avoid OOM iterating a broken tree */ > > > + set_bit(MMF_OOM_SKIP, &mm->flags); > > > + } > > > + /* > > > + * The mm_struct is going to exit, but the locks will be dropped > > > + * first. Set the mm_struct as unstable is advisable as it is > > > + * not fully initialised. > > > + */ > > > + set_bit(MMF_UNSTABLE, &mm->flags); > > > > Do we still need to do this if !mpnt? > > No, we probably don't need this now. But it still makes sense to do > this considering what we are saying. There is a failed mm, let's mark > it as unstable because it's going away in a moment - it's not stable, > it's not even a complete mm. > > > > > Also 'mpnt' is in the running for the worst variable name in mm... > > > > mpnt is the oldMm vma Pointer, Now isn'T it? I think that's self > documenting. :))) > > Thanks, > Liam