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 0F032CF538E for ; Wed, 23 Oct 2024 14:21:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 422EB6B007B; Wed, 23 Oct 2024 10:21:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D2C66B0082; Wed, 23 Oct 2024 10:21:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D73E6B0083; Wed, 23 Oct 2024 10:21:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F118A6B007B for ; Wed, 23 Oct 2024 10:21:18 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8FC31A0C7B for ; Wed, 23 Oct 2024 14:20:46 +0000 (UTC) X-FDA: 82705079226.02.4EA52BE Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf18.hostedemail.com (Postfix) with ESMTP id 59F401C0022 for ; Wed, 23 Oct 2024 14:21:07 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=dl3MwHIB; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=fgiATHQb; dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf18.hostedemail.com: domain of liam.howlett@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=liam.howlett@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1729693223; a=rsa-sha256; cv=pass; b=o7ObY/XAdaZ1+7rdA85v5jmVYbuWPu1a49fkjR0PtTXDsBVR5eoDBITEhM1hA5pViatxbe 5fIKmUUmxDpqYdP9/lNf26a1oHx33uvAWUQLLgoFSK7ydScP41uv4YcOcio7uI38tKdphT QxJDncHB7X4iuc1R7j57rrpEabX2cuw= ARC-Authentication-Results: i=2; imf18.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=dl3MwHIB; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=fgiATHQb; dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf18.hostedemail.com: domain of liam.howlett@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=liam.howlett@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729693223; 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=Q0zHbup28wzgSJlKAXT4ziF4Ca++U+XGEnuEyHCAw08=; b=HoSXhcXye18tz1JN4HZch8HXzMS3syRMfw9kN4aTF4pQxmxLYrS8vEE8ewCvxb7VV1HrTQ 1RVjYySVObwuGZ+P04qwWnjoFpckNS8DWjTq7n4o1mHgC5KLEwxC8Xst0D8Qks4Yp90uyK MUp+L+04bXXdunv6ZlKRBUr3tVxMFW4= 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 49NBQj0X030913; Wed, 23 Oct 2024 14:21:11 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=Q0zHbup28wzgSJlKAX T4ziF4Ca++U+XGEnuEyHCAw08=; b=dl3MwHIBWu+k1y55NL3redMWvXf2L2U9Vp dSwzvIk87ub6XQwZMMq7oBQTv9XKQcjZbhwYJuLLMO2Vpebl5FR06gS1hyAGqQOn 0ZqKD8rHZhlfb1ELneIpT6IjHOYtxu3MrJ4P/Hm1GYIrV4Y7V6Jk5C7n/7AYoHqN a7U/x9wOV0/ptCoxAkNEhnTqNhU7RjI1gI4+DjIbx/yR8hiB7tL4BICR56968He8 MiT/WdmuOEpFX4yay2uHH22+VquxO9TvPU4cxEHwYSo3RtVOAREoYa7FPc485JRW zQsyb+oR5MbcqZfaQ73/d/T7hutbfvKsD2KAieUQvOT8GMQILb/Q== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 42c55v07ra-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2024 14:21:11 +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 49NE9TmK036009; Wed, 23 Oct 2024 14:21:10 GMT Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02lp2041.outbound.protection.outlook.com [104.47.56.41]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 42emh2kdad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2024 14:21:10 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rg47t57vs6fSEOGNsM6twIinpZe8Ax7TekIiK4ii1h9fy96oo03vCibfc54uHZeA/PYwNPKFfyWfJrgyJQu43QAVap1HUBAbyZ23XPb88eGyaQ4bDD17otbmDAv6vHV/5Xwx7ZY/c/QWLTYNSSVFXgLs7cQoVpbOWxxsePL7iDsuQZStjq5fEI8hiynomkDbcLIvV1ps/YsddNzf0PYoIvD0xLoFeVUGxPTd4/T4OaNr48htCz69lL8kdSxvrY19YtqjxLKT42mehD+83Y6a691erVb7b9PPRyvhskxC2gAmMkSfvpiBDN9/0b6pSfCSAUyZoRG58nerlM67/VE5OQ== 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=Q0zHbup28wzgSJlKAXT4ziF4Ca++U+XGEnuEyHCAw08=; b=toQKNVfvIfnhRh84DkHwlKWeSkRnb+JTykLl8oZTh52wxC0vG97umIjNQuPE8mZ78pnldMjOLPNpNaC4npuY6qMQ8nc6RLjLJ2qr3WagCh6FS+oYQghQB+ApcHJFi58pRvvWziRHQiJdUKvTsqINxnHYBn0aOVqJEsQ1GL9s0KuLS5p/QFQ9Y/iu0FNilUhUMBeeA1vDGqWv4NA43VxvAgFGmGWfAYOR1XR4hSYZPpzXi1yJejygoIWkFj+MQjb/85C+dHGpO969juLupLT22h9qcOOmjOGUM0e5Q80ueHX0GJTsg7w5o5GzGff+OD+RpWhL2f/6Cg+iAkjHP30MRQ== 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=Q0zHbup28wzgSJlKAXT4ziF4Ca++U+XGEnuEyHCAw08=; b=fgiATHQbA9ra8frL+e3NIcpDHtu5q/LY142XajOCoqcJrUrKV3gvXEAiI2izo3uXUYTR9JS6JD2hhc3kZbnMMX3u+v1UpPYSTWvsMn9Zr2LkLUgdoq6xgVogGFoTwL2hotfOazOpUx//op54qb7dn/i+Ir5wHR2tywkxTxTgSyg= Received: from DS0PR10MB7933.namprd10.prod.outlook.com (2603:10b6:8:1b8::15) by IA1PR10MB7115.namprd10.prod.outlook.com (2603:10b6:208:3f4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8069.28; Wed, 23 Oct 2024 14:20:52 +0000 Received: from DS0PR10MB7933.namprd10.prod.outlook.com ([fe80::2561:85b0:ae8f:9490]) by DS0PR10MB7933.namprd10.prod.outlook.com ([fe80::2561:85b0:ae8f:9490%7]) with mapi id 15.20.8069.024; Wed, 23 Oct 2024 14:20:52 +0000 Date: Wed, 23 Oct 2024 10:20:50 -0400 From: "Liam R. Howlett" To: Vlastimil Babka Cc: Lorenzo Stoakes , Andrew Morton , Jann Horn , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Peter Xu Subject: Re: [PATCH hotfix 6.12 4/8] mm: resolve faulty mmap_region() error path behaviour Message-ID: <73wl5i2vmh7fckairzw5j5so2fjg6p3vvxhixnpqh3zc64o7ys@yidsexyjkrs6> Mail-Followup-To: "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , Andrew Morton , Jann Horn , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Peter Xu References: <3bc3ef7520eed73472f7ffdce044f2e94f809b32.1729628198.git.lorenzo.stoakes@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20240425 X-ClientProxiedBy: YT4PR01CA0067.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:111::22) To DS0PR10MB7933.namprd10.prod.outlook.com (2603:10b6:8:1b8::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR10MB7933:EE_|IA1PR10MB7115:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f54762a-520c-4844-1246-08dcf36de64d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?mjMQBPDje63pUPgDFk3q1M4r6o7Ylgr0cjuIvRKEel0RHM7dm0bdol0H/bgq?= =?us-ascii?Q?wrRvaEcjQomob64WfXBLkAtbUxbhX0NVYOEK3dJVwJ4cPNsqy+16qthnDGoo?= =?us-ascii?Q?pHN0u76oUAqh7OyoLn/dbcKQkN96M6jmagbcxr9wPq3MLpNDATitLDHDcP9x?= =?us-ascii?Q?qP4QIYOaULH6V+AfHktW/k6h35a4jfjaJLqWPyIqGN72zg+YeO+0/bc/NaW0?= =?us-ascii?Q?fB44yzxrsNSTpXu4IjsvzoWW1Bc4ZGGv564euXhTCwzpSk+TUqkdjmrE4c+a?= =?us-ascii?Q?OmTrEIjK8mR0G49dZWLwMJ3vPC86a4rfwkrNoG4rVoomeZMSC0fez9PfSP/k?= =?us-ascii?Q?gIZG1J7BafPtRcsg5osJetoxkLu/u4kAuAaFhCA2B1nlqCORDZypj5AS/t7S?= =?us-ascii?Q?xwkzS28/oISQw3mF/Q6UqQhs+lOsYZqpPX2LtZYWEDOz/H7ro6/psIpZZra/?= =?us-ascii?Q?4dfdiH5CcDxWb8JoxQPWwhlAToOA4COaLanZrVjtxBmdHDvYLzXhRvNmCwpe?= =?us-ascii?Q?lKbyGPd0/V3z2j/5xvim4bSz+q66AFRIFulsxQjX2NpcQAY4ZYyskLOKkALq?= =?us-ascii?Q?EoStqAJhMSQJ6ZZGun4WPw5sYiEh9TF5U/0CqgKq7LR2qs5bpWFuTeJacM0h?= =?us-ascii?Q?zyLVAgKTiYKoThzu7C4y6I08rsp1j2P0kXgO8oGarSXw1sMoyCNVOF7hrQU4?= =?us-ascii?Q?xj0CEoGe/1s66y8MXnmWhits2KDka0zj7Y/gAZGBnxK7n6kV/Pa6Kq1mZyXo?= =?us-ascii?Q?zxZWtL2ZKsc1SvGUb/shYTMZ6tP4ZZWmLo09kgzOYAChAsLJD2IjExyRQuhV?= =?us-ascii?Q?aQPIXrnhibzfI5pPHXsRcM09/dpbbCPzyZ6SKEwsBXOrHxeq63YUA1TPj0j2?= =?us-ascii?Q?y5jwFbeEvQ1Wb3nNwbBqblQCJSm8tZRHh3+TP+J0Z9Q/qY+rVylaXAg7bk5s?= =?us-ascii?Q?PFcZcHGkP/R3AkG/AQ9bIiyx5LZS56493JbBH4ekYv8VeCKxzT3PVZqebBRj?= =?us-ascii?Q?pxxH/RwMhcT3iqDK0BOfPBTxMnSQzJ8+/VtZ/bK5AsrNaPQpjIVdUsRlxPO2?= =?us-ascii?Q?OyqLr4A9fgahR41b6cTz/AxgxV+dKXTJxl/4G6bPayM0j5hjzrZYPd/KBmmW?= =?us-ascii?Q?rKZpWhCMOqz/ZRZrqKfQmre1HC0Y/TdnBkunj5wsmkWkBZFZai1MdJGBzeoR?= =?us-ascii?Q?iBlquJ32zWvw9xRvC3GI+/MA8ethRWSiu2CDsYWGP4L+gYuadVvGC0IG4AP+?= =?us-ascii?Q?l7/JOaL/oITgL0WqqReEe0kMOShL4Xgrw8ueo4jVTE7QhTo2MdziRulJeZ7O?= =?us-ascii?Q?4ZSpZT9boxaI52ypNOBo8OrH?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7933.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bP+qetepmVulgiGe3b9d7OGdXy8nMsgMK4xApQMM8QpPwokW4PwWutOghwja?= =?us-ascii?Q?dETgN7fgqqb91anDzyxU5Wfr1j2fHLrKBB1h0LW9kOcQxdP2PTIhEi6kmzI2?= =?us-ascii?Q?eseoVLcsVwTt+BcmIWexW7vJleZ6kKr8RamH8Hc9BWXcMkxQNtzqIb+t3qGU?= =?us-ascii?Q?ohNPiZzzjdvot8SOJ20vk1dWyOCSrptCaRAjxZhys8sk8fCLfC+l8H2msU4b?= =?us-ascii?Q?DPwMxNsVz5ZQunU+VaI9VV673xk4kOkRJKLae602TWG3G+bkNhsmTnQvVcm+?= =?us-ascii?Q?iP1LrYLD7OJ7QT7yef6Flc4my4lYQIOLii5eSMU32LCvGnzRPs4DU/k47TNt?= =?us-ascii?Q?d9ce4XWmX0CaHTfVgA3AHuiT1GIM68HGuvDcI2Nwe+L7yw7tECusZWEBYRiS?= =?us-ascii?Q?pQmkTUxfNP0+cRDtImjK1E8PEhLc/nlUfeMHQwqmm1bedohovlFNJN/vxLV4?= =?us-ascii?Q?MuED+vObqOJvMSNtkLs93wPf+lREhrjbBcgFf1PRM6pTyrR5vav/ANQHLcR+?= =?us-ascii?Q?ZTtmuo1BOarSG7Qm2O4Zjmbe7g32IMx40w58o//i4C/RuJtSiNLq87y5k6M7?= =?us-ascii?Q?Bhesa+c9GgOUN6wmg4Qfl0yDyw6yycCu2mSwhI+310Hc249/LvuI4GZBQGlD?= =?us-ascii?Q?QonNCjOUe5PP6Aj6+ACPHNmUpQ808NLRFCyQ4Z6hR3Yt7HJzlNgjKSYKW7wV?= =?us-ascii?Q?hT3hijTsbyEZqwlsA+VT9hfVgGcA4AILLaVbnLtRjDd+rssx2WocTt4Jyt/x?= =?us-ascii?Q?SqmLEy8V431M+2pY3Rqr/S/FA+qhQj5Q7Zi3TEWB/qYcl5Uyh9Ku+Txr83ZF?= =?us-ascii?Q?f0CgGoCVkghU/a6S4WO/olbIEmVR3ncpps5Veu3Pwv3UfWjSPT4Wa4z5w9ib?= =?us-ascii?Q?TvMVK9vpIWIbTyxOPo9br62kEzdCUcCTqXsRg1VLcp78G6M3Bf56ov87ULO0?= =?us-ascii?Q?v/NFGaJ3Fwj9CGM+yIBVtuN439eK+InNg3V2DnRl5R2ZfouCJVSqJOGoG0nS?= =?us-ascii?Q?8lM3Gqw28LJf0H9op3vrDcN49aX+TOf/YVi+H7c9cJNxtPXwHyT+Jdqqv64N?= =?us-ascii?Q?bpHxkQR9szpQhiWmEzcDvuqlXCX+UL1bg0Pg/PK1rJmJOamARug566ebowBL?= =?us-ascii?Q?eMTIwjgO1Ym6+qJGT3mSuERpWT2PG2xQVUUHY0/lfVnqnl+NzHSk6M+BKSrO?= =?us-ascii?Q?0dAu0caFmtqEiBo9aguXFJaso76M6c9W3uedX+g/IMopU+ul/P+M0yFuZMle?= =?us-ascii?Q?r6u+R6rSM16Ce5Bvu5GlYQBlj7IBFYJZ6wzgYoBI69RBKRAkOUKU88psh6p7?= =?us-ascii?Q?zk5OnrscJR+t8YWFAiBsKGZJ6H7BSVDZcFnn75utvFJF++lnX8ef14vbDQUz?= =?us-ascii?Q?6NBGXdeVu7+kKSRaDM0xJfJFV9LQgR4lH6D7SlUdoTKQ2IgthMsNxEujPSL7?= =?us-ascii?Q?cPdpM5pVg8fVE6+gyrwxK7lG56uR/XiS6ffB0tVtyuu8m4VzNfh9uDpN114i?= =?us-ascii?Q?xFztWk0WiVnfPXDrZ6bRuJkTA3QZqb9oBUtUg8QDKrg1l3+rGYxUZfJl45nS?= =?us-ascii?Q?I0tn5OCqmH176S4ZoZu0AHYc56MOn+wccAFctXda?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: w3jwlciQ/BngkeuDoxBOtAhU1qO9lJmgjQr2ZGJENQaWzTsVbgl6fMpPfRLmzRDua9pfq+4JmW/DA8daXvaOUFKg5ee4QdwmtY9HI1mBLF38TLNmhpYXzYms0cqgMUAMKo1GsTP71+tiZTf+7wCGO9qV97iNPCGMytWR/+6Z5LadSAGeR+uiGxU0P8VCEX5n5zZiYixpBayZvM2WWrjmvsqUW4mYTxmMnJEy9iV/V+oRDHj2DCqQ6qfRZplLxYVqFdmnI4sWUCuDSog31dM8R8OkdcmIwJtAgnyUXynHsqOxLlbMNvXHmXRKoSJsh6kRltj9Smv8m/aWmbLxYFxwfGLySTOFZVGNSjNRLv5Z7jv13ToKTY43thKSjGzT2YEfKeFytheaCV2TItz+UQckacpgpxVOVy3UEPrSG0+Ab81Qs+ekQCIgVVADdKX6PY0YyTHcFhcGVH1CR6jIO/8Tx9rYqjXYYPC1UBCpV7szLRCkLDOvQk7mnPJRRGHTGuV4oMK6P7TgU9p009FNPv1ea3QA7oAJg54JdSsxp7q89l9g8r1NOgU7LS0/ftAsACwmnJXBh5WkAQP2TxPyMbf2Y2MXvWZKiJhaINm2YLGBddE= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f54762a-520c-4844-1246-08dcf36de64d X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7933.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2024 14:20:52.2631 (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: CsMh0Khs1n9K7QOH6AgeeiuxihKLRE+KTtyQPMZUj6Tvp4eBN8OllCTty538+OxGfWbTw6zpiU+uRwTGkIg2Qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB7115 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-23_12,2024-10-23_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 spamscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2409260000 definitions=main-2410230087 X-Proofpoint-GUID: urd8x6qYu6aKQUhdi11SmfdNC5uJr80Y X-Proofpoint-ORIG-GUID: urd8x6qYu6aKQUhdi11SmfdNC5uJr80Y X-Rspam-User: X-Rspamd-Queue-Id: 59F401C0022 X-Rspamd-Server: rspam01 X-Stat-Signature: ud1bhf7qixkr31k7iq8rs6tr95dapesi X-HE-Tag: 1729693267-758920 X-HE-Meta: U2FsdGVkX19cX6B4vpzbZ0INDH3ZJsQam4TlJAFCEs09dFHcDoOdA7AvuFDr1WDt0mW7Pl9olPCRJzWeSZucbuMZ2ktRhYe0aLDlE2YU0lv8+kRc0jQ/0eFhdeL6y0WuMH2nKBaX8iIMycuJyB2ERf9WYH7E+05TQAW42+hmqu1BBQVMoGyxFt7J4mUs+GzdobZNh9K5Etma2FOgbgKnr1JZ0iO6g5A/p7yxjO2s35d4W16yFVdANk2w2DvWPP/D+X6xRhu65N8Olpp6bAFpHntnfS4NiyrsLO0OX9OJR7f0WLlhRt6efJDZsSomQIMWQ4i6WvXN12/jBTMommRN+ynMnpyVja+R1LH5qgqJ9bJuZmiyaDm5V1mMgO1BXsVJVdoAAo19hC7Jom6LTkuZ2ycTu68MAkkJIWI5Y2Smh6jdHcQKh/Z6iliPh50dXv6lXiLwNOoXGu13WGGkL+syGCfbgGTvxvPGVuW27+xdSgGZuq3j6gZLdEEaM5ViJdH4pMw8PNEeZxXzRtu8XBc1Cu5Wgc4nPTRd5Rxj6NsPYdNvITQpUQlWQDDNHxK/oFRrRouyMhQZ2gwtKqQtWi8RKC7bubjLI9LKpp4n23W7xKPxhgAEWwIpZS9h5B3oMlsQchL92FjGzxvIV7U+NVCdQOr46bPPXCQ0lVBmSqK6J/OcebBhmHmfgkBzh4DGM6jr73JLYyn1ZSLNq7l2MU8S7A1VTZQ/wR4/71nukQrNx/AiQggdr7Sh0gCPY8LOmEjXXPmbG5HGlJuspmQhLUYAGLCgUbGp3zYXkwWRMkuIaVDlcdOu6GdxbSm/+1PCmZ5pSPP1EB4aT1l3RZIvMd9XQoB7yHhbgUI/NKYaTkQYZ010TT6ELsVYXwairqVY+zPpu4ChgqPTzIztdyhgwMSzFFlYGimLhiFrge8KwjZH3a6FtM5iTSDWN2hN4L5lHP0z+wg3/58yhYsgldRMVvQ p4CYXOvv xtSS4PgW0o+Fr4Ywlz1rCXKv2J63o4y2G3DO2JLM6+ULkWS1Q4tWmL3gx9T7Q/9TgAk2KslvcDD8B5KoLJyUqwWUE5W4uCYJTeslS/zWsYtGVfydI4e+gfZkN8jZs/Y72kzibpNH9QuINMFW8YbAFv4w7bQulZEgkTun0qrZ0GkCg3GqZmv5AZtOI9pzHRhWyJXkie2FXRZDk4beCjS7Q/f9/0uZ7YFnxWVofIpcs7Mwp8DudnSGAdHMncpZYh6eyoICI2uGx3O7n1A+tVbKpbWrRtFDZizZYbW4hg0OMJvfwSuC+O8FlF1GzmQBr+27jaPZjXifn2L3J8r4yo07/lFPAUaCxuINmZFdebyVk9EibIhzY3l6g5vfN05jiF3KJa8uFFMuy4SesOqtl7Um4cGwto6t7B6HpiHESI/6RCkd9yEHAUJI8dlPOVA6JPDWMMJJgP7kCm0oG809WUiAQEe90G5mEq+PA+iXw5+UPtJ4A5Ai+gNECBq8+rY0nMuGTNieHXz5JzZEtGqIYDDuP7DgcbPag1U09VFPmv3a6ClS/K7+kfmlEVFDIAyjT41JanGPpiMgRcf3rgKQW/YtnDgaGGBIuU2ColJ+oWte2hRXVpTc= 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: * Vlastimil Babka [241023 08:59]: > On 10/22/24 22:40, Lorenzo Stoakes wrote: > > The mmap_region() function is somewhat terrifying, with spaghetti-like > > control flow and numerous means by which issues can arise and incomplete > > state, memory leaks and other unpleasantness can occur. > > > > A large amount of the complexity arises from trying to handle errors late > > in the process of mapping a VMA, which forms the basis of recently observed > > issues with resource leaks and observable inconsistent state. > > > > Taking advantage of previous patches in this series we move a number of > > checks earlier in the code, simplifying things by moving the core of the > > logic into a static internal function __mmap_region(). > > > > Doing this allows us to perform a number of checks up front before we do > > any real work, and allows us to unwind the writable unmap check > > unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE > > validation unconditionally also. > > > > We move a number of things here: > > > > 1. We preallocate memory for the iterator before we call the file-backed > > memory hook, allowing us to exit early and avoid having to perform > > complicated and error-prone close/free logic. We carefully free > > iterator state on both success and error paths. > > > > 2. The enclosing mmap_region() function handles the mapping_map_writable() > > logic early. Previously the logic had the mapping_map_writable() at the > > point of mapping a newly allocated file-backed VMA, and a matching > > mapping_unmap_writable() on success and error paths. > > > > We now do this unconditionally if this is a file-backed, shared writable > > mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however > > doing so does not invalidate the seal check we just performed, and we in > > any case always decrement the counter in the wrapper. > > > > We perform a debug assert to ensure a driver does not attempt to do the > > opposite. > > > > 3. We also move arch_validate_flags() up into the mmap_region() > > function. This is only relevant on arm64 and sparc64, and the check is > > only meaningful for SPARC with ADI enabled. We explicitly add a warning > > for this arch if a driver invalidates this check, though the code ought > > eventually to be fixed to eliminate the need for this. > > > > With all of these measures in place, we no longer need to explicitly close > > the VMA on error paths, as we place all checks which might fail prior to a > > call to any driver mmap hook. > > > > This eliminates an entire class of errors, makes the code easier to reason > > about and more robust. > > > > Reported-by: Jann Horn > > Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails") > > Cc: stable > > Signed-off-by: Lorenzo Stoakes > > Reviewed-by: Vlastimil Babka > > some nits below > > > --- > > mm/mmap.c | 120 ++++++++++++++++++++++++++++++------------------------ > > 1 file changed, 66 insertions(+), 54 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 66edf0ebba94..7d02b47a1895 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1361,20 +1361,18 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len, > > return do_vmi_munmap(&vmi, mm, start, len, uf, false); > > } > > > > -unsigned long mmap_region(struct file *file, unsigned long addr, > > +static unsigned long __mmap_region(struct file *file, unsigned long addr, > > unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, > > struct list_head *uf) > > { > > struct mm_struct *mm = current->mm; > > struct vm_area_struct *vma = NULL; > > pgoff_t pglen = PHYS_PFN(len); > > - struct vm_area_struct *merge; > > unsigned long charged = 0; > > struct vma_munmap_struct vms; > > struct ma_state mas_detach; > > struct maple_tree mt_detach; > > unsigned long end = addr + len; > > - bool writable_file_mapping = false; > > int error; > > VMA_ITERATOR(vmi, mm, addr); > > VMG_STATE(vmg, mm, &vmi, addr, end, vm_flags, pgoff); > > @@ -1448,28 +1446,26 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > vm_flags_init(vma, vm_flags); > > vma->vm_page_prot = vm_get_page_prot(vm_flags); > > > > + if (vma_iter_prealloc(&vmi, vma)) { > > + error = -ENOMEM; > > + goto free_vma; > > + } > > + > > if (file) { > > vma->vm_file = get_file(file); > > error = mmap_file(file, vma); > > if (error) > > - goto unmap_and_free_vma; > > - > > - if (vma_is_shared_maywrite(vma)) { > > - error = mapping_map_writable(file->f_mapping); > > - if (error) > > - goto close_and_free_vma; > > - > > - writable_file_mapping = true; > > - } > > + goto unmap_and_free_file_vma; > > > > + /* Drivers cannot alter the address of the VMA. */ > > + WARN_ON_ONCE(addr != vma->vm_start); > > /* > > - * Expansion is handled above, merging is handled below. > > - * Drivers should not alter the address of the VMA. > > + * Drivers should not permit writability when previously it was > > + * disallowed. > > */ > > - if (WARN_ON((addr != vma->vm_start))) { > > - error = -EINVAL; > > - goto close_and_free_vma; > > - } > > + VM_WARN_ON_ONCE(vm_flags != vma->vm_flags && > > + !(vm_flags & VM_MAYWRITE) && > > + (vma->vm_flags & VM_MAYWRITE)); > > > > vma_iter_config(&vmi, addr, end); > > I wonder if this one could be removed, earlier above we did the same config > and neither parameters changed? But it was true before this patch as well, > and maybe it's further refactored away later in the series, just noting. Yes, this was here in case the vma changed address, so it's probably not necessary. > > > /* > > @@ -1477,6 +1473,8 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > * vma again as we may succeed this time. > > */ > > if (unlikely(vm_flags != vma->vm_flags && vmg.prev)) { > > + struct vm_area_struct *merge; > > + > > vmg.flags = vma->vm_flags; > > /* If this fails, state is reset ready for a reattempt. */ > > merge = vma_merge_new_range(&vmg); > > @@ -1491,10 +1489,11 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > */ > > fput(vma->vm_file); > > vm_area_free(vma); > > + vma_iter_free(&vmi); > > If we merged successfully, I think this is not necessary? But doesn't hurt? Yes, it will use the allocations (and re-allocate more if necessary) then free the unused allocations once this call path reaches commit_merge() with the same vmi, which is nice. And yes, it is safe to do regardless. To be honest, this whole block is so rare that I want to delete it anyways. > > > vma = merge; > > /* Update vm_flags to pick up the change. */ > > vm_flags = vma->vm_flags; > > - goto unmap_writable; > > + goto file_expanded; > > } > > vma_iter_config(&vmi, addr, end); > > } > > @@ -1503,26 +1502,15 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > } else if (vm_flags & VM_SHARED) { > > error = shmem_zero_setup(vma); > > if (error) > > - goto free_vma; > > + goto free_iter_vma; > > } else { > > vma_set_anonymous(vma); > > } > > > > - if (map_deny_write_exec(vma->vm_flags, vma->vm_flags)) { > > - error = -EACCES; > > - goto close_and_free_vma; > > - } > > - > > - /* Allow architectures to sanity-check the vm_flags */ > > - if (!arch_validate_flags(vma->vm_flags)) { > > - error = -EINVAL; > > - goto close_and_free_vma; > > - } > > - > > - if (vma_iter_prealloc(&vmi, vma)) { > > - error = -ENOMEM; > > - goto close_and_free_vma; > > - } > > +#ifdef CONFIG_SPARC64 > > + /* TODO: Fix SPARC ADI! */ > > + WARN_ON_ONCE(!arch_validate_flags(vm_flags)); > > +#endif > > > > /* Lock the VMA since it is modified after insertion into VMA tree */ > > vma_start_write(vma); > > @@ -1536,10 +1524,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > */ > > khugepaged_enter_vma(vma, vma->vm_flags); > > > > - /* Once vma denies write, undo our temporary denial count */ > > -unmap_writable: > > - if (writable_file_mapping) > > - mapping_unmap_writable(file->f_mapping); > > +file_expanded: > > file = vma->vm_file; > > ksm_add_vma(vma); > > expanded: > > @@ -1572,23 +1557,17 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > > > vma_set_page_prot(vma); > > > > - validate_mm(mm); > > return addr; > > > > -close_and_free_vma: > > - vma_close(vma); > > - > > - if (file || vma->vm_file) { > > -unmap_and_free_vma: > > - fput(vma->vm_file); > > - vma->vm_file = NULL; > > +unmap_and_free_file_vma: > > + fput(vma->vm_file); > > + vma->vm_file = NULL; > > > > - vma_iter_set(&vmi, vma->vm_end); > > - /* Undo any partial mapping done by a device driver. */ > > - unmap_region(&vmi.mas, vma, vmg.prev, vmg.next); > > - } > > - if (writable_file_mapping) > > - mapping_unmap_writable(file->f_mapping); > > + vma_iter_set(&vmi, vma->vm_end); > > + /* Undo any partial mapping done by a device driver. */ > > + unmap_region(&vmi.mas, vma, vmg.prev, vmg.next); > > +free_iter_vma: > > + vma_iter_free(&vmi); > > free_vma: > > vm_area_free(vma); > > unacct_error: > > @@ -1598,10 +1577,43 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > abort_munmap: > > vms_abort_munmap_vmas(&vms, &mas_detach); > > gather_failed: > > - validate_mm(mm); > > return error; > > } > > > > +unsigned long mmap_region(struct file *file, unsigned long addr, > > + unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, > > + struct list_head *uf) > > +{ > > + unsigned long ret; > > + bool writable_file_mapping = false; > > + > > + /* Allow architectures to sanity-check the vm_flags. */ > > + if (!arch_validate_flags(vm_flags)) > > + return -EINVAL; > > + > > + /* Check to see if MDWE is applicable. */ > > + if (map_deny_write_exec(vm_flags, vm_flags)) > > + return -EACCES; > > The two checks above used to be in the opposite order. Can we keep that just > to be sure we don't change user observable behavior unnecessarily? > > > + /* Map writable and ensure this isn't a sealed memfd. */ > > + if (file && is_shared_maywrite(vm_flags)) { > > + int error = mapping_map_writable(file->f_mapping); > > + > > + if (error) > > + return error; > > + writable_file_mapping = true; > > + } > > + > > + ret = __mmap_region(file, addr, len, vm_flags, pgoff, uf); > > + > > + /* Clear our write mapping regardless of error. */ > > + if (writable_file_mapping) > > + mapping_unmap_writable(file->f_mapping); > > + > > + validate_mm(current->mm); > > + return ret; > > +} > > + > > static int __vm_munmap(unsigned long start, size_t len, bool unlock) > > { > > int ret; > > -- > > 2.47.0 >