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 C8BD8C02194 for ; Fri, 7 Feb 2025 13:12:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 078996B0089; Fri, 7 Feb 2025 08:12:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0017B280001; Fri, 7 Feb 2025 08:12:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6E096B008C; Fri, 7 Feb 2025 08:12:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AEE996B0089 for ; Fri, 7 Feb 2025 08:12:47 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5A7CE14190A for ; Fri, 7 Feb 2025 13:12:47 +0000 (UTC) X-FDA: 83093188374.28.DB7EF8B Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf06.hostedemail.com (Postfix) with ESMTP id D398118000F for ; Fri, 7 Feb 2025 13:12:43 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=mCCYhdQH; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=iVt9a48K; spf=pass (imf06.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1738933964; a=rsa-sha256; cv=pass; b=vjzRL/eJDGmEn+lhyT4AV/LAN7Alye9T8iv/PNWSkB6yPZIzfZaMMQ8WP4jVylVWTT7fdM UjIISiLJJxUIKUiYWoc7ltFfspJzYT9i2IYwWwvXbHVQnh4Rv+Hs7K2uc8GvAmbOTjRvLz f/567tPAOkLyn6CxiRqTGJtKQWkL6hM= ARC-Authentication-Results: i=2; imf06.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=mCCYhdQH; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=iVt9a48K; spf=pass (imf06.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; dmarc=pass (policy=reject) header.from=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=1738933964; 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=gOqhi7OBK9+mRy4ZpvN0Q/GHwcA/9yLHvQkkcvp3u2E=; b=TKG/cq7kTzrrnLDiiMlDtppzNebesQ0UVEDDQV8wZQeU/mnh3cMOoN+gzF/HbzbcPMWuGg D4b7pPgdxBRUeeI1rsZr8ieM9uV/PNzK8orX6AKASRUUBZsGP/AbW60jswhEPX+5/eQjMq 7icoekAuhW/v9VdScUcp3lNTYLy3/vU= Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5171tt8a014648; Fri, 7 Feb 2025 13:12:41 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=gOqhi7OBK9+mRy4Zpv N0Q/GHwcA/9yLHvQkkcvp3u2E=; b=mCCYhdQHm5HUnU1S2dkO+drlB0e9KxDBS8 GWtjTKS7zd0SWhCWv+uj17nkQv9YlylPUNoMXTtLruM3lww0qkP4P5wR9hTVuwi2 /FDpN30fKGkRClmp+0Y93MBDYaYZAhhtR7fQH+D973rHEf/fk1iI2stgnB9ZfHtf 1C0n7zVpzTfEx4sEtT1TFVt18PZ6QgXQcgAIie3zrhf9DPlAHQsiFpx7L+eRnfQ6 2nIcCACxczLk/lhuBqspnIEeltZPGIWgR79kUvoMEXMdUEYxZ8FMmtbunTC2ZTN8 5usXC+rp/5L7BBzSKKbUxq3SmweJa7PxCGTQ+2BH8WhFHJPRxffA== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44m58cmq8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 07 Feb 2025 13:12:40 +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 517BqR2X027114; Fri, 7 Feb 2025 13:12:40 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2043.outbound.protection.outlook.com [104.47.55.43]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 44j8frbkbp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 07 Feb 2025 13:12:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qdc7vm78CgjaKoWUoPG0sSxgURVaiDSGDJlL/gM7qkpUPn9UVzKyqtTD2UoMqYRAMhN9d2FGD+OgdFl0Z8AM53SVaa7yvovKszWbwYUnAm9QMHXozzAP5ZYcc/WXqGcj337gvDy2pOWgPEIjchZCFyiHCgZCX3y7xZmGgk3JFTeejEJk+jd2fqWggmp50RuugBOv9lkP1CGcJ9Wnl2I4kYzi68nNm/x2j8/cvNh9DsZh6rzfVIhSoRaP809syQ0LQjbUfbolgbWdxVGgxXrf4JoLq+2/hQQL5Z1BXGnQQqDmK6m6ne0xBds3LoR1JMbJ36GHPDYsCqXe5RqLtloBBw== 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=gOqhi7OBK9+mRy4ZpvN0Q/GHwcA/9yLHvQkkcvp3u2E=; b=eGCAIYamjD3yANMY2jmaJf2IJoFc/3ct4OqyHUSMfpFKw4SCmelhzpQndMckEzP7XZ1vIucNXSicr6C96C/PGpeIaUbMuA+Kl5to6AWVMMfvUMxwmiCXbDvJZwBZnHT0tPYTdc6OoiztWc+pC/XRu+5URhWnrV7nJ2/27p4bj3DZWPqMYpIcn/lKl/cW/Ba4gdZP9eqxqPCy4mwFnRGPsH37SDcy9KvrFJupwf0bjpxiDTJsLZgT0wQh404bxpaye0uuu1UT/RKeTDjJ/zA63jkIL86FqJPMyc/GDmH1kx2CUdrFTHuARCbBuuCIDuNebXEfrJ67V55rEroG4CZUyg== 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=gOqhi7OBK9+mRy4ZpvN0Q/GHwcA/9yLHvQkkcvp3u2E=; b=iVt9a48K2EUUMjXysWA4KJiX+ih/C05f3ugrQyUKNoC8pwhJsbh1uc8TfGQNTOVY3siP3W5xwVEK6qLOzBUycoyY+BQwrPNdtNfTVd/+JEhNdsXlG/L9KnV/5Gh2mhcHjRNg6GceYraCmFdJR5ogZXaS6wd294vKPfCTtHvNyhQ= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by DS7PR10MB5182.namprd10.prod.outlook.com (2603:10b6:5:38f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8422.11; Fri, 7 Feb 2025 13:12:37 +0000 Received: from BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9]) by BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9%4]) with mapi id 15.20.8398.025; Fri, 7 Feb 2025 13:12:37 +0000 Date: Fri, 7 Feb 2025 13:12:33 +0000 From: Lorenzo Stoakes To: Uday Shankar Cc: Muchun Song , Andrew Morton , Joern Engel , linux-mm@kvack.org, "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Oscar Salvador Subject: Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions Message-ID: References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO4P123CA0261.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:194::14) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|DS7PR10MB5182:EE_ X-MS-Office365-Filtering-Correlation-Id: d67bca6a-7c71-4112-e698-08dd477917f7 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?+tUmSfa5k+KTtpr0AG+KlTv4PxiGj46PcmVwymDatVB7570JiYJMujPcSrYY?= =?us-ascii?Q?j/rCOaaSGiRZAnx5J6RQydwztkc2n1CilgJNFmdyiNuxKBFIZM9YHB1zgM+c?= =?us-ascii?Q?T8EFJKEq3ER6x0PLncXmISMfZQV5evLTuMJ64LTBkYF2HBbq6uqLtPY/DXh4?= =?us-ascii?Q?uDDFdYzXXS12p7XmEx6H4W2cefm6CLILkNc2knQomzI8EHA5KFVI2fNeJ1j4?= =?us-ascii?Q?9lqzgu6E/19hgQqjE4ArXXgcwCJYx8/A7YEOJmjCtcrFGFcObyYgzTkQJDAl?= =?us-ascii?Q?ELvfmqfwtjj/IS7LR0bNbaJPRCFJa5SfVMcu4EgBSAIS9K980G+1NuOY0pOd?= =?us-ascii?Q?3tHsJD234DSCbNkB0baTUE3B6Mk6SvqVGNc/zh2d3m+nOeh/JNSxkz89NtZe?= =?us-ascii?Q?REZ0ROhMGwB9QUsqxOj9l5jA+dqeM22GenYdOfuFx1xJpCA1FrNUhs4hTCIP?= =?us-ascii?Q?s7XkqEBHI4/W9Y9fKi9buTchoWbsFoKBkkjZ0k1oMSVsfkOM7UrT+P01jFAw?= =?us-ascii?Q?N3hIP37w42IeLilQmaYXoZrSYF9EkyIjNWUkCJaD5gmzf9dp9Gy3sWhYFWDG?= =?us-ascii?Q?QmTTRf1vECpBA6LzGYrmdCAV5dED2xRvNnSxYe06NNHKXr+U1Wjuyn6cmFTt?= =?us-ascii?Q?1fFL2OEKReAGqvxsCyQS7M3hX9I954W7WBcrxYydakpyM6SSuvwmQxf3/rP7?= =?us-ascii?Q?6Mri287Je7fC/dH12hDkIOuVw1PAhcrF2XVHE5N0ej8uGuhOb3VHIwkKOIFK?= =?us-ascii?Q?sRPpkmVcOT0QMFNRvhGh8JlNTmxOTfJLjx6lg5mmiADMcvLo7c/Lv6nbDb8D?= =?us-ascii?Q?JUf2v7W2BI1jJc2ztzY/ySPJk6Wgq20CQ2XPJfeREIv//es2azzRW9R+ca0T?= =?us-ascii?Q?VifjCr/n5r4lggAo9tEm/DQFNxBq0d4pdchzlW/lwaYXNvvycMYSseXT94FX?= =?us-ascii?Q?TM5rGJt4UYBcSgo/gw46RyZcygfdOMvTXSXcf3S99X85Uf+NFrHBLCJkXNqF?= =?us-ascii?Q?d/EKp7El2xXqOurtejSMhMbjBMAk0kprPnzI5ObbEjQDFbWwHc9VY1nV6NMv?= =?us-ascii?Q?EWNCYWv4B/AaArmgvajlNNhTrmAHqB1Kkdh5BDR+VrOVW50AfX4tF2Wh6EPM?= =?us-ascii?Q?MnqBvWP5PX2wEZEP1NHtdJi3vTPHLE5cnTJ6KeqWaZSCIjH5T6spdy4sIrQg?= =?us-ascii?Q?nSzgWCvZYHt7Fc4RUacBRCV2vwFibDUhGXFP8W+ZRKHAqvMFwZL4wZwlQMoa?= =?us-ascii?Q?H1e6O14L1dPGTkKn+wnIlY4R87d8xO1NtUS37LWMJhNs0udkdIt/Xj2jOSsE?= =?us-ascii?Q?y9r6qTLMNMlKwtZdHK2E7aURb8sCDFEHJ2DZ8+7OXMxhZvhidDKkAIoNnOd6?= =?us-ascii?Q?fhtwRGuFGitmUJImBAQpyLDxaBVt?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR10MB3366.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?XfkANscVpp9csTH1LXFhDtlQtE9qMfgeIAvn4aCJF3Ab1Sn+6E9OmSfRnxiY?= =?us-ascii?Q?WcXnvZRjT+L1fT0BEGM565vtkvitabMwBS8/EdYL2gcOpByOT7C+LFKzDyu3?= =?us-ascii?Q?8c4lN+IrMu1238OIl3EVDqMyirvArEnhXBO+CsaLq/9N2DfXtyiTzSMqbjP8?= =?us-ascii?Q?wobrjDZsxGm5jg5mPGcMcxFj0agda+ZQ6qyDSGICWmnvK1jefxdJjL4LC0xR?= =?us-ascii?Q?khPV98np3pqB58Sg1dDhnAPfisDhu5pnH5jTemMMeUhN4yVMCQBwGaClkePA?= =?us-ascii?Q?MpjT9xr0NIYxWwLbiTm1uPrWBFRv/hpOBGejSzn+w0lTbgXmaK7QZQEdgKss?= =?us-ascii?Q?+XCchO+cMEEkwO+zcVmH3IqzJZVb5kBjQVLbG9p73G8PbJ8pUeUwPDNgWUYJ?= =?us-ascii?Q?UyddTO0GzfycsHXTXtkk7KoPWVWo0KERXrly1Gy8HQtjRzoJ1PI7SG7Tp0rs?= =?us-ascii?Q?IX4w/jbTvhab4gY1u3hySykXAPGOM676yR4PPIeExgZL/Iytj3gZ5hxUVYDL?= =?us-ascii?Q?56wEXL14b2796lNBq64v4To0tfsWQolU3BwEriebOfoDoMpLqdAnmav9UOO9?= =?us-ascii?Q?EcoI1pJfpuJKki6Tkeodl5nWMnKm+qTKn4Z8u7wdgRiQpmbKEM7Cr7mRbgGV?= =?us-ascii?Q?c0oB9wEjq1Nm1l92AEvWSpJTNnOT2LuWXtQMr7b3EadJYKtRxiolrmpHdych?= =?us-ascii?Q?WLJu1eMjSPBwxicTVJzU3bBkyvoRdEQWZJ9dz6Szm3DWB+lqhjdZ6YpkQlEW?= =?us-ascii?Q?MwOZRaCX0DJvD09e1y0ZyuLXgTyXs1nxD62oiL2eXccnmnpZwsF7560fbswj?= =?us-ascii?Q?dNuzffhqS3fiSf+bAWorT1jlOjyUhc36dO6V55wad+QJTRxN4k42obO2MEJq?= =?us-ascii?Q?VRTbskfRXjzTFGxgFRhoNZcPEdFxpHjZ0mwty2U8AtcwtYuL92NEkqJftbWB?= =?us-ascii?Q?ILUbFNOgKeOi2r2vhjbSDOh4HJpmaPQfWM9fKfrQpasQZGywJMj8oEAlLXEg?= =?us-ascii?Q?rcUrC0Q16jg4OiJ5eB/L4JtDGOX1ISqLR9pSlfkSQveRZ7C6m9u+YciDUNwg?= =?us-ascii?Q?jhgM0YPJdLAGR0Lr7viN2zODMKyv1Wen/oHCtdNuKcVCy9bzag2iPxKTWpmB?= =?us-ascii?Q?sf5MgJVp/QzfORTojShAX6iPoYG76GFe/+PXey/U1tBEk94c8cVm56AbQOht?= =?us-ascii?Q?n/AB47X7ll0RMrQGJfAR20ZCJL7j7yQhBXy4g8nGyiVxReXC6HpVkQ4L0Wop?= =?us-ascii?Q?zRpL2UTa0CRHNMF7w0F8w5Hu2eXmJMQl0bcBv/rMRKJbJjLE4tx3AVF1B2Mq?= =?us-ascii?Q?1aSkFd7fUJmpvrxLqICXybYrmJHShoBgi5Zc4VGFiNNbGypVOotXEGMeC5Wz?= =?us-ascii?Q?/EBpDv7kJ//9nXscNGy0nIBjq/qTVXdK4b/r7rCx1xC76vuUWoGiGtKUS9qj?= =?us-ascii?Q?VK8ts/qHY1uefBPisrKJ2t4zEBAN9K2itKGIa3MvJJ6kcwCQk2uwszNoEjad?= =?us-ascii?Q?zxZ/j6IxUmRY+53Jl8XwUAhQjqaFeXhDSGdZREewNGbw3RNGxqHitk4Z7U/4?= =?us-ascii?Q?Es6bi/KvMu+pkBHiKboiO+NJS6VlF7zUu8ykBuUy+BLlL/nnOR3YWG2AueTk?= =?us-ascii?Q?zQ=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: XV3NwAlN5q4gHGYBdH3d7g6DLwg9zM0GoObtdvF9eQ8gdzGHT1V3jAdlOE2hT6YldM4WNK17atiYg+Xc9v33PxImYXHOYh07qBT5BIol6Y3SImkyYKjfSMLe1+D0ABrs+2d43Arcro58J2Dp+RZvGdWfNodSkFvKsUvmXAX69eFbsrq9rYNcGYqWHTvuzrf65h5MWvBZXaUSNzXtQSaccHUohK8SekKIQAL/zV46CwaWtdZnsQoNbIziQcY/v1cvqEVx1uRraZhYZVIcz2rBaniAdxgL33Hoju+g78BatQLKlHHy2TTATlfB6iGhSSnywm9WSX/XJexqluXAcuc8LLNdT+/0nMBQ45dh1Kmu1XV/W8CGyPuddeRHiAK4+cVAjedUsFXd0YYdKdCdo3f2Z0RulmfrONKgGkmQ+EX4sD5FfbVso/P3ivOx/pB/tqexGMz9faRG+w+yVENjimksT2l17zPd0g8dRqFxcvKa9SUppVt0sPqwGVGaaDJW9cB8GULhyMsBxE3ZVDUnJLtRN/KRJYGxCz3rmLBfYoG/UXgvAJwHh/+RRWDVwICm0CzKKPsaR2VhLdFvPuKxq9CEN5JdbNpC1ZYYrlUXyPU7Wno= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: d67bca6a-7c71-4112-e698-08dd477917f7 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2025 13:12:37.7734 (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: iaA23nXtv6SATFt/Nw1g1KojO/rN0TRj6Aqz7hV2SiS+6vQvVTzUUoOR/rzDAXOAlTG/0N1kTHwH3CSm38AylaZc2sRkPYE4AiOcLZBKjBQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5182 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-07_06,2025-02-07_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-2502070102 X-Proofpoint-ORIG-GUID: LhVq8eExVE4BGCHzR4TScSRlz8r7Gt92 X-Proofpoint-GUID: LhVq8eExVE4BGCHzR4TScSRlz8r7Gt92 X-Stat-Signature: ujtrdkj8rsyn9zp6n69k885g76665goa X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D398118000F X-Rspam-User: X-HE-Tag: 1738933963-425692 X-HE-Meta: U2FsdGVkX1+1QKGW0UIgNk9A10/NOjrHN/aLh92eOfFlJGQbxYc8SU5JFsbT/ni5OoQ+F9wzw7/c+tNX6/PjKRYwPcI7ijFpY0G2ELlm6M4EZH0rr4G0DsYlhmDOStNl7ubsQ0e3W3doFebQ+g6p8ZK14RDXr+LgGqT7Fc38EP5itbf3HW5ZAbmlTPO5mLOKdFE1hrt9ZfP/R6/UxkKXu5/ahjcGu4MTYd8OCRlpwnRzDe2uIQpXpMWz8++XoWoHGMrTo9ZCE5tTHbP5s3zfPvShgk1T1RSa4TZSsDx0ZxKU5jpj0aXE1Zpc9NHNIvho8DdWYt5zF7P74NuEu2Dp8KorkDife/NNNScgLMvklQ1n0vUNqIFvVYAXsatap7nQ6SsqGxNwjwqXIbzUxWuJ9xcDUSJJU2Soaj7ZhhC4Z5fp/gEXJeJLbtL7MdfehKNbKy/vwmXiO3IBtzSw6WQrLmTyP6PDmQQcuXH8QL0cgZOdXSuWZQVuWkmv5n73lmdYwBiphX0IwWqzvDFkPTjSXTxSamEe3v8lmjumqBMcXWJIn8fH3ajwQ5yUVIIMForHYRMDgWrjFy3U6HsM4NX+vu9p0vtc0VaH2Kuc1+cMSxOPPWLg5iI+kF01fAz17K9DhM5/kR2rV4JSTSUiUYOpHZ5CWshUsj76n+7Z6QY6CAyweaQEs7Wq/DfeB1OqSX9arpxiJAqCyPiieIChwpJsKglA9XpvtXssATMw50XLyNqweQr8XCDnEHR6Poh97n3SCdXUSjKDv5pTre438bjTNPwn47ifSxMfwQs3p65PmsHrsXSLcbE4/ONMKfUA86xdLqsFGfdvcP8DHPQA9NTurwWSjJK/1OuaIgl7OZXIbWxlZPJnbwJ2V3q7n/BN9mz1doGUKHGTmSGHfN67xMhui2m5/6Kq3MK912Kg/wTZwBVzMS07q6WxOyX6BuWi0V0Nr4GJTy7r354TE/eT7xr Pc61rLJ4 SIVrxCFy2o/a9ECiHguW8uz4J18Sy3f37xS7Zr8rsKYqOw6wEja0ajXgoPmPK3jZMp6Op28JgpafjMgSBLtjcz1GgnXq8WINAojSib4UYbXkMUTcZUO6o65woRhZ+HUJ0tlkP78R7PTMrKU5TRjkjBnZr4AqNXCR4M4g9SnektoK1pqN02StdYsRCYygUUtoRbk1EN+4r5ADW2eATmQ9VDQ1dIUGjKub7Ubamc4hdSQsXAeOxkZQs7/R49vDdkVNXTF+V+Hj/JUeoMWfc1EvystVYlnXRR/rgSU2R7utX1M2DnoJQnVL3PSvrcgHXOCpNJCSC/8FgFdt/RSqIko5KXbfgGxoRMEVDI9M093TLkaARroaPXLm5rg60BH/04NrA9+vA/nInzzL/ALSmEAafacyDKkKZeZzUrTZDy530Y/7cJDOvSP1fJtSqJ9Do2ns5wfAOYFxdhF2PE9fY21BauX1O390V6PYkmUHDtdTltCXZYMzjVAscA749POJN2sO1JTO3l4HBh8hhEBrHCh3TOQogKQnScjm3OJoXWQEmRMk3Ygq9u2Eq+NAhVt9Y9hVUwRxnYuHsLsMsiL4JAbcRKabbeazOcxk67BoPr4ThejxXxFg2N6wVR56UKkkhjN1sI6m4 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: Thanks very much for your report! +cc other mmap maintainers/reviewers + Oscar (thank you for pinging me on this Oscar!) (you weren't to know as a bug reporter, so no problem, but the people listed in the MEMORY MAPPING section in MAINTAINERS will always deal with anything to do with mmap() and friends swiftly so it's a good resource going forward if you find anything else :) On Wed, Feb 05, 2025 at 11:18:34PM -0700, Uday Shankar wrote: > I was debugging an issue with a malloc implementation when I noticed > some unintuitive behavior that happens when someone attempts to > overwrite part of a hugepage-backed PROT_NONE mapping with another > mapping. I've isolated the issue and reproduced it with the following > program: > > [root@localhost ~]# cat test.c > #include > #include > #include > #include > #include > #include > > #define MMAP_FLAGS_COMMON (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB) > > int main() > { > size_t len = 2ULL << 30; > void *a = mmap( > (void *)0x7c8000000000, len, PROT_NONE, > MMAP_FLAGS_COMMON | MAP_FIXED_NOREPLACE | MAP_NORESERVE, -1, 0); The MAP_NORESERVE is key here. This tells hugetlb that you do not want to reserve pages, but rather to try at fault time, so it will make this succeed even if you have no hugetlb pages. If you try to then fault anywhere in the range, it'll segfault. This check is done in hugetlb_reserve_pages() which is called by hugetlb_file_mmap() which is an f_op->mmap() callback (the MAP_HUGETLB 'cheats in' an fd so makes it a file-backed mapping despite apperances): /* * Only apply hugepage reservation if asked. At fault time, an * attempt will be made for VM_NORESERVE to allocate a page * without using reserves */ if (vm_flags & VM_NORESERVE) return true; Actually though this is irrelevant - you will see the _same_ behaviour regardless of how you map this. > printf("a=%p errno %d %m\n", a, errno); > errno = 0; > > char buf[128]; > sprintf(buf, "cp /proc/%d/smaps smaps1", getpid()); > assert(system(buf) == 0); > > len = 4096; > void *b = mmap( > a, len, PROT_READ | PROT_WRITE, > MMAP_FLAGS_COMMON | MAP_POPULATE | MAP_FIXED, -1, 0); Here is the more interesting bit. Let me analyse what's happened here below. > printf("b=%p errno %d %m\n", b, errno); > errno = 0; > > sprintf(buf, "cp /proc/%d/smaps smaps2", getpid()); > assert(system(buf) == 0); > > return 0; > } > [root@localhost ~]# gcc -o test test.c && ./test > a=0x7c8000000000 errno 0 Success > b=0xffffffffffffffff errno 12 Cannot allocate memory > [root@localhost ~]# diff smaps1 smaps2 > 157,158c157,158 > < 7c8000000000-7c8080000000 ---p 00000000 00:10 7332 /anon_hugepage (deleted) > < Size: 2097152 kB > --- > > 7c8000200000-7c8080000000 ---p 00200000 00:10 7332 /anon_hugepage (deleted) > > Size: 2095104 kB > > First, we map a 2G PROT_NONE region using hugepages. This succeeds. Then > we try to map a 4096-length PROT_READ | PROT_WRITE region at the > beginning of the PROT_NONE region, still using hugepages. This fails, as > expected, because 4096 is much smaller than the hugepage size configured > on the system (this is x86 with a default hugepage size of 2M). The > surprising thing is the difference in /proc/pid/smaps before and after > the failed mmap. Even though the mmap failed, the value in > /proc/pid/smaps changed, with a 2M-sized bite being taken out the front > of the mapping. This feels unintuitive to me, as I'd expect a failed > mmap to have no effect on the virtual memory mappings of the calling > process whatsoever. > > I initially saw this on an ancient redhat kernel, but I was able to > reproduce it on 6.13 as well. So I assume this behavior still exists and > has been around forever. > As Oscar pointed out, this is not really hugely _surprising_ in that you may be requesting a hugetlb mapping of 4096 bytes for case 'b' but by setting MAP_HUGETLB you are asking for it to be aligned. So in effect you are doing: 1. Perform 2 GiB mapping (it actually doesn't matter if you make it MAP_HUGETLB with MAP_NORESERVE to make that succeed or not, or even the size as long as it is larger than the mapping you make afterwards for the purposes of the discussion :) 2. Map something over this _partially_ where the mapping fails. So the crux of the point is something that Joern alluded to in his reply - 'should a failed memory mapping operation cause visible changes to the memory mapping'. The key point here is that the operation you are performing is _aggregate_. You're not asking for one thing to happen, you're actually asking for 2 - unmap the start of range a THEN perform a new mapping in its place. So the question boils down to 'does linux guarantee that aggregate operations, on partial failure, unwind those partial operations which succeed?' - and emphatically the answer to that is no. If one of those successful operations is 'unmap this mapping', as it is here - you have to ask yourself - what would undoing that look like? Because if there's anon backing, then the data underlying that mapping is gone forever, so we can't restore the mapping as it was. And at this point it really makes no sense to special case things like PROT_NONE, because we simply do not guarantee that we do anything good in this scenario. Attempting to 'do everything up front' would be prohibitively expensive, imagine the overhead in tracking that etc. etc. If you get an error performing an operation, you must interpret this as 'the operation either partially or entirely failed' and act accordingly. This may be surprising, but as you can imagine, correctly performing unwinding of partial operations is... difficult and in some cases would have significant performance penalties. An important point here esp. as to Joern's question re: an unmapping partially failing - since now we gather up and do unmappings on MAP_FIXED in aggregate _internal to the kernel_ - if the failure had occurred there (it didn't, it occurred in the mapping bit) - we WOULD HAVE undone the partial operation. The problem here is that we have SUCCESSFULLY unmapped part of a mapping, then FAILED to map something in that gap. So TL;DR is - aggregate operations failing means any or all of the operation failed, you can no longer rely on the mapping state being what you expected. ~~ Beyond here lies extraneous details for the curious... ~~ HOWEVER, interestingly, there is a little more to this story in this particular case - Liam, recently significantly altered how MAP_FIXED behaves (actually interestingly ultimately to allow for far more efficient interaction with /proc/$pid/maps and friends but that's another story). And he _tried_ very hard to implement the ability to partially unwind these unmap operations, and this was part of 6.12... but in this instance there's just nothing we can reasonably, as discussed above. Now - _had the failure happened on the unmap bit_ - we WOULD be able to unwind, by simply reattaching the existing mappings (that is - internal to the kernel - VMAs). HOWEVER, the failure here happens _after_ the unmap SUCCESSFULLY completes. We track the unmapping operation with a 'vms' object, and key to this is a field 'clear_ptes' which tracks whether we've cleaned up both page table mappings and actually executed on the unmapping. If true, we haven't done this yet, if false we have. We set this false after succeeding at the unmap here: vms_complete_munmap_vmas() -> vms_clear_ptes() -> [ clears down any actual page table mappings ] -> [ sets vms->clear_ptes = false ] And then on the new mapping we do: __mmap_region() -> __mmap_new_vma() -> [ error handling ] -> vms_abort_munmap_vmas() -> [ sees vms->clear_ptes is false ] -> clears the range and gives up. Looking at the code: static void vms_abort_munmap_vmas(struct vma_munmap_struct *vms, struct ma_state *mas_detach) { struct ma_state *mas = &vms->vmi->mas; if (!vms->nr_pages) return; if (vms->clear_ptes) return reattach_vmas(mas_detach); ^--- here is where, if the operation failed during unmap, we'd be able to reattach the VMAs and go about our business. But this is not the case. /* * Aborting cannot just call the vm_ops open() because they are often * not symmetrical and state data has been lost. Resort to the old * failure method of leaving a gap where the MAP_FIXED mapping failed. */ mas_set_range(mas, vms->start, vms->end - 1); ^--- This comment is the pertinent one - we have no choice but to do so. And this is what is happening now. mas_store_gfp(mas, NULL, GFP_KERNEL|__GFP_NOFAIL); /* Clean up the insertion of the unfortunate gap */ vms_complete_munmap_vmas(vms, mas_detach); } Prior to Liam's changes, there was no attempt to reattach _at all_ and we just always added this gap. Now we attempt to reattach _if it makes sense to do so_ but the case you've encountered both previously and currently will result in the behaviour you've observed. Hopefully this clarifies things somewhat... :) it's a (surprisingly) tricky area when it comes to corner case stuff like this.