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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 45C01D2F03E for ; Tue, 27 Jan 2026 14:40:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91E326B009D; Tue, 27 Jan 2026 09:40:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 893CB6B009B; Tue, 27 Jan 2026 09:40:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EC256B0099; Tue, 27 Jan 2026 09:40:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 47A176B0099 for ; Tue, 27 Jan 2026 09:40:47 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DB113569FF for ; Tue, 27 Jan 2026 14:40:46 +0000 (UTC) X-FDA: 84378005292.03.518616F Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf15.hostedemail.com (Postfix) with ESMTP id 1BA5DA0009; Tue, 27 Jan 2026 14:40:42 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2025-04-25 header.b="AkcqH/Po"; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="R9d8XC//"; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf15.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1769524843; a=rsa-sha256; cv=pass; b=Z37bAp7H3u3fP3U1ybjf1nxPwIrd27Si55JLa1UtACAxA/2Qv3EMprSGG0nwrs7fBcDOMj v7jJHmn2Rn3tQpfQmvnvDgZ3gynkzSGwFiVbqnBWfYXPki+3O+0q0mMI85u15MjAtTYLiI ADEodFkb2vvPqab6T5HZkVktaITUzGk= ARC-Authentication-Results: i=2; imf15.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2025-04-25 header.b="AkcqH/Po"; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="R9d8XC//"; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf15.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1769524843; 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=hxAbCl6xauJtwWwZJdaNuV0GnbN6uV159d3n0RkObHM=; b=M84AW97+yEB1Ab+IDVf6lAWXPr1i7NR0lVQPUYf834HVBL/2K6eVOpqIfhqzTYCevjV4lQ fFYeRelUOm36SKBJ4UrhSSscB5ROPCWLkiO/zupFw3uAN1YkdUCLJ/39reb6NgWLMTxOf2 Bbf3iWQ+cyM0gOlR8QusBZEs6wUFHC8= Received: from pps.filterd (m0333521.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60RBHiNt3544802; Tue, 27 Jan 2026 14:40:15 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-2025-04-25; bh=hxAbCl6xauJtwWwZJd aNuV0GnbN6uV159d3n0RkObHM=; b=AkcqH/PoCEr8P2eLR4Y676TdbCzbwCSYnb xAC5jPgWSObVWGBXtnQ+hxMf4WZd8ATVAnZVvguwbnpnGhfpPy/gI2GY6xMPqfcm N4wDTRoGHf8HKq5URGdHrjyJo1UKy6z2TkKdP+kd1fqQeefSQV889TX0WfQMBUum y0F1V2RnG+k7FgiMyXN3SqfqWxpNr9n3ZS5RJlpiOqR6695884FqzXt7Ggr+FfQe ULNfBA+Znj1tT0jH3TkEHuHQs7X2BCA2ddjIXME5u1lBYScHbx11zVw7jPWqHoi3 sRmkPc71TT5ec1djXWaF5WV3oWfF56qbwynBVM7l+oM0z2fPsw4w== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4bvn09m4ya-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Jan 2026 14:40:15 +0000 (GMT) Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 60RDVk2N010011; Tue, 27 Jan 2026 14:40:14 GMT Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11011051.outbound.protection.outlook.com [52.101.52.51]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 4bvmh9gswe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Jan 2026 14:40:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XiTUkMVIolbmgkTqFp5+ZiTwI0T6C+ct5y86MuIKsyl4BTcHdsVuveiqsf5GViZdhRWy0rft86zxL5L/PRVEU8KN4GFeGaYjrWluZRciRmn8M+HaVNXhD7MDS8zsG5OeqmgqM8fQWh+SOM9tiRphrehFQftcwIA2Hbb5bb/VefbyoU2vDp2ebEkKuRYA3oneB0jEP9MX25dSpViqa8nNL4Updm8fSsAcnsSLVCigO1nu9486p7G0ZHNehLfWwUsstH84J7dW0QKSjO94qRZNAm4X9rj3iwEQPBIejjHcV2IQQMum/su/7ewlY/CfxfOBsycdkB+YkUGt911VSpQcSA== 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=hxAbCl6xauJtwWwZJdaNuV0GnbN6uV159d3n0RkObHM=; b=c3r9tXitaTBRR1nqPesBqrpg4pF8BPuPkuVc7VD92RW6rOzkcIygvkIKzOnPWWxMCkJWhHxQDJMaHZf1hFpwSSLZKpz8mUcZ10TbkAVcvhzKnC0/cMoOBCJmFAXrolWvlWW6whWNxa7UuZh2kw67t7FGvn+6YSYqaM3ps23UrC35CbpHKRORbatslq0qNSaFSou4hjoEOh8fI7Yaclm39VPRbTHVam9ppHpHqCjmHrjCCoQuCNXM59TbTIuAWlf1w1YhNlvk68Cm3FENOE4dByOaEN1wOszhNYHubWc7p5ngTogQcQSIxsvCLXdzQgQ/C/G4Av6epOsr5oTTutC3qg== 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=hxAbCl6xauJtwWwZJdaNuV0GnbN6uV159d3n0RkObHM=; b=R9d8XC//IbCWe1/wbSlDyX8Z7l4uMivgrzxO9zWziim1prsBRKPjF7yUbHvHzoCklhzWhUMp4VsoyvxfuLcE8ImEvrjT1lTcj18NqHWBGg0pqVgQ/1O/yenTIV+3f1H5ZYJuyx+yN7/YsuSMFwvjaF6bMRN2TggLVDgP8uCS9js= Received: from BL4PR10MB8229.namprd10.prod.outlook.com (2603:10b6:208:4e6::14) by DM3PR10MB7911.namprd10.prod.outlook.com (2603:10b6:0:1e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 14:40:05 +0000 Received: from BL4PR10MB8229.namprd10.prod.outlook.com ([fe80::552b:16d2:af:c582]) by BL4PR10MB8229.namprd10.prod.outlook.com ([fe80::552b:16d2:af:c582%6]) with mapi id 15.20.9520.005; Tue, 27 Jan 2026 14:40:05 +0000 Date: Tue, 27 Jan 2026 14:40:03 +0000 From: Lorenzo Stoakes To: Yury Norov Cc: Andrew Morton , Jarkko Sakkinen , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Arnd Bergmann , Greg Kroah-Hartman , Dan Williams , Vishal Verma , Dave Jiang , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Christian Koenig , Huang Rui , Matthew Auld , Matthew Brost , Alexander Viro , Christian Brauner , Jan Kara , Benjamin LaHaise , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , Theodore Ts'o , Andreas Dilger , Muchun Song , Oscar Salvador , David Hildenbrand , Konstantin Komarov , Mike Marshall , Martin Brandenburg , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Carlos Maiolino , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , Matthew Wilcox , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Hugh Dickins , Baolin Wang , Zi Yan , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Jann Horn , Pedro Falcato , David Howells , Paul Moore , James Morris , "Serge E . Hallyn" , Yury Norov , Rasmus Villemoes , linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org, ntfs3@lists.linux.dev, devel@lists.orangefs.org, linux-xfs@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, Jason Gunthorpe Subject: Re: [PATCH v2 00/13] mm: add bitmap VMA flag helpers and convert all mmap_prepare to use them Message-ID: <5f764622-fd45-4c49-8ecb-7dc4d1fa48d6@lucifer.local> References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO4P123CA0357.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18d::20) To BL4PR10MB8229.namprd10.prod.outlook.com (2603:10b6:208:4e6::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL4PR10MB8229:EE_|DM3PR10MB7911:EE_ X-MS-Office365-Filtering-Correlation-Id: f4828e7f-6b73-4f34-fc4f-08de5db1f60a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?/tRkUjMvZxbwUaEm+rmh6mnApZK1cKSDDFgFgNTafwSJSOV64aElfLVBV8ni?= =?us-ascii?Q?3Tmig+J6c3khynrZXF6V0exDV15mIe/WPwfI9jQjFbsCiyy/wB4iXUbf4U5g?= =?us-ascii?Q?t9J8qOsdEq34o0zjuQQL098Du07GNpwWWrK6uPosv4edqvFw017KpwXt6FQH?= =?us-ascii?Q?iZPSx0MPLZuHBsYtyr4jIXI2lup5Vs38pWe/MM4fEKOy1QuO28C5qeJNc/Y0?= =?us-ascii?Q?yX8TRZvcmfH6/80tFrI/5bngRer300c1EZrhyLLcPqFtufIpILV2pinm7Pjo?= =?us-ascii?Q?iPBmpQvf5FNfMz0M+15ni0QsO6IOonERosVWzvX9GH91wffElpn1KevlPzLH?= =?us-ascii?Q?7r8OWiXpAPVQGslxVG7xIIvsWxYvCjlJjgAQMQCbeKDTTRvwd/2ropdJq0nM?= =?us-ascii?Q?nbrtX4Z2QhGTgIOSorAx97ff4Vpgi59o1dImUAtJlhy8evaM2ksDamw4erCD?= =?us-ascii?Q?7ORR5HIlWRJyvhm6o+YGq0JkWI+lbJ2+GL+RCLGGdscqCRSaKMAWzcje5s+w?= =?us-ascii?Q?x/Y8bLLVB0xwXpkaRIlGi70njJ8SZVYdSi2VL+fL5kV7HB8ZaadHlWetOs7j?= =?us-ascii?Q?nc3WFaXEkHCsisPjJkU0tASVcwzf0V1oibfRvHW0mk8xXwyeD+EAX2Etinv/?= =?us-ascii?Q?Jsoh1nyaM2I9DFM/QnBG/IW+u6MKGfLqcyn+LgFEkEm/SEM8Ty0cBSwgYrO5?= =?us-ascii?Q?syIw62fEXH+MYvJbv1q36gC1cfwSKnWR5npPdCeNbUuuX7flnGW3wNxHZHgv?= =?us-ascii?Q?NyxqecNK9ZRSNd7VPqMnAT0JiTPlM7mKLt4cyMV+lYsanUQOzYfZ/jcY+gjT?= =?us-ascii?Q?eOOBuuSOOEcNtk8fRYrCQ5vDdVwASAdThDpVGqlWHxzFsx4GlJGCDUmpO8As?= =?us-ascii?Q?kR2Fx+ScNVG0xT0UCTK14Xo1HvkuPFUUm0yqPr94yDPJzMug1Kccmjav8+Me?= =?us-ascii?Q?0US7j5I1CgZsljjLUhc+3HG8dJ/tvplDaVMAnCgmquO2nnA/Y4Hj2SU8pJUX?= =?us-ascii?Q?dUDEzuhcL6TuUFyScElBPdgm2y3gNhYwZFTH9EaduYM2qaMfYeyVa4FEoK1G?= =?us-ascii?Q?Fg3KaRnbEgqe1nyUZuKOWPnRjwt8NdB/jp51b8YHPsWwlWtyxbvXif1fVj7Y?= =?us-ascii?Q?4qrKrZfr9jbcmicBXcB/pcPmlCHrcwgne3mIjxTO6dcUedT/aFoef/aG5lpW?= =?us-ascii?Q?qGol5xDOdcvYEU5qFxy4yLkFgrBt5xe/Z7QjuhufZsoMHpmKRfuoP7klmolo?= =?us-ascii?Q?GXRMxtdtl56wzZf69tLgS2it/0c5c7IIk4/st1MN2WWxsMb1e0DBFuamfdP/?= =?us-ascii?Q?nNMlNa7w/4if6gtQ5uEhxY4orlf/dMynUBmrXuKEQ1fAmqKFXbXqhTZ9jNF4?= =?us-ascii?Q?eh0dnPnMcI3XBog0j9mXAHXjoAcoYpgjZPODVKX7Agj+l4ykJbOmKsZNW23F?= =?us-ascii?Q?6T4ZO9SszWyMsPQstcQ6pJ8Z5dlTjN3aSTbH49n+CTdQv6YSSQdOi2iWZ2Hw?= =?us-ascii?Q?Vjb3YuoPWIAfgLh7mbIWHm1Rp+yvk/3Xjv91bs6ufZwd5g2mtq5IBXB9gxv9?= =?us-ascii?Q?sKlxKentor5zck15Uzg=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL4PR10MB8229.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lw6ozjDBRQ+SvOz5T/oG5SQUTY1VdcUuuUhoxNfIesJvRn2thrueJ9obnXmm?= =?us-ascii?Q?PyptrPce56d22Kbmjl/yXQmX1ML810unHT0ARcD0Mj6S153Rmkn5rO0xCqTV?= =?us-ascii?Q?F+0+1I4MyBI6X+BBUxZSwqH+3lm3CfZ9DNkMXoTMt0fi3WwbpCEQw7wz3oE8?= =?us-ascii?Q?ynJAqRhdo0+1AP+4njm9jvrFsjXAOvRJZZtqTKT16a5Jrnzyg3BjiR37pOv8?= =?us-ascii?Q?fAJ+pjzGGTbtaTjBxzv42socSoGwh8WxfJvpGQ/IY5QIOyoyHx7+jGVnvU29?= =?us-ascii?Q?4Zd0S2+S4/CydLzXVV0WzqDmQkJDy/cmm0r/1frWxVHpF1sewDnIM/L2JgUX?= =?us-ascii?Q?cxWvisc85XImJevYDyIz/IeHMFwrCwoZEs4HeRcUkQWIx1tqxR+3KIvs/PNm?= =?us-ascii?Q?dFd+bawFzhTp11dBfQ8M7FA45JbZpwi1nQ8pHuHCJHbDdePR2MjBWbWop1K0?= =?us-ascii?Q?ugN4/jJv9fnl2Q1afIDxMYjyOeFrum9QNMrVv35e0V0oX9WCSkZ5Ra3hsOzK?= =?us-ascii?Q?ML+6dIObx5Fd2PX+c8gLityQ1pYYoLPEtWpLVlUhKoyyZihOKfJAcq+iLY/T?= =?us-ascii?Q?5zkSF8iFQjQasjgcafbjhEjhd7HKWGLVUDe+bTqM9GvZuy2u1OsOwe/Ofxlq?= =?us-ascii?Q?GrstFEU+TucuFCpUwfPSFXBj0oSG44I6IbdX4idfNHtrn2ajkMFMg6mX8w9n?= =?us-ascii?Q?hcuDFKqhI2rI7YfkJ1FQhM6Q7z8HFI2NuYV7dYKsZZTyFP/hViwMl3R/Ukcn?= =?us-ascii?Q?QjLj0Oz5ws8rhWMAxLHYPCfo/7zHwU78TtTT3ZqQZx97IZRYLKeFcqKrZyR7?= =?us-ascii?Q?fNhiLNaiMscyMbo5zezC8gd0fgZ4xK6y+esocXerfo4UfhSs9sbLOgpiih5L?= =?us-ascii?Q?G6zkbjHQEgby7MkO1sy/HnvhA8PO2fM541YqnAa/6tDtiGmnsbc0aykw4hJ3?= =?us-ascii?Q?3p9uEvnKpuHsg5fOLXPfxXR4U6gY/cHJqbMFfbOvR27CcDQYglyCiT1SQ5Pr?= =?us-ascii?Q?/8XXQFOkjxccEUAxJuT0eRCXjBwE5u9jroAKn3Yw4uLut0mdO/8OcRt8Pbuv?= =?us-ascii?Q?AKqnzIw9LHmMpuuwZlFpqj069UO6wABYfhu8kWNCeaoXz60JPd1qfQQN4+VT?= =?us-ascii?Q?0i7E9gopkApY6ppdkiRVWnMK42U2IU0qz0GyiHkSTFNsm6Te47grU1sDS/lP?= =?us-ascii?Q?y2xWUrLYyCmgpl5IlrVBgUoWtbNh5e+HOQB0KSLOCFbkq1GU9jIHj5sQ7JT8?= =?us-ascii?Q?2ZKbZHR2zX5SMP0FkQBiL78aljq1uIzmEo8YnYzjzpw3roAeQnDtkPXQRz/R?= =?us-ascii?Q?fft7sq4w3GLomWbqXTQotw5G3gHnV6zpRib2aJb9cKzo6AZy0tu7Kcn6YbHT?= =?us-ascii?Q?Lct6CVSPlJ9xkxNGfQevT9Tzi/4UrrDkXLP9R6iJaQ5dm5Aa4aMLnfw19Shn?= =?us-ascii?Q?jwfBrhwBMlirdA0rDbS1xdhKnFXMLNYWDMJT512ju9sV6rHGQcHoRt+nVLWb?= =?us-ascii?Q?aR4NVOqW7lJdDdZiVMiXriCTaGcWAGYG4ddPmPEtnbbf6IIACJGIvDLQN0QN?= =?us-ascii?Q?PlPAH2Mrxj5koqshy3LxUI03NQ5EsxrnYiMZBl85JHwEeLG890OBP5MgIbQc?= =?us-ascii?Q?MDYAiK9vSGyGAbWb+PlUcAAuyLbGQRuRyC0zYQ/1gVdjDoxx/OzNyqI1cKHC?= =?us-ascii?Q?Tre34ZYS03TH1Xif3CeWctBGYlUe2dLxtOfgpChrYHdmCOig8siZkG/tX0Oj?= =?us-ascii?Q?dyEB5HvHvOvOgvBv/72eiHfpokUtaNI=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: QoEnN4NoK8UeHTvoGqZE9/IiYHscQ3t8Z9LEcr9R6m+gaof/LnX0M3cy5miyh+m1bxJkaWF9OYHf6U8fX/zOYJCMACwuoDTmWexEgs5gInzZgnLk1Kyakhv5fNzfN52DUvv2xUhE+UnO24oc4+69lG+u75Q0C2cvuOlmUQ9v4haGE5wE2bwHH7xm6mOnSFoSx/QH7qAKcfoK79f0wX9QC2F3g31D2+2kId24YTAwwVKDvTBxacf4c7SXgwUrVJm0cYaSuumqLcvcajSKMo3h5xsMd10k63FVULQp0eLu4tB4o6GOUqKM6IPzEuNXuSoi4ymRGKPOF0TrvMk14fo+vwaFZB+PDujrfrMguhC0lYfGLIhQNlxaeRY7kwRSFEDbc/9oj/rxVIuQD+sBSc7lLwdMj43i3daVOjjP1CRem8PGf9KiioNNPBf1f0az+NoL0B8uTyBiXfEs4lKQ9mPwRp7lydv3FEvwxmil/Mxuz5UOoUyNAwEqq9URJ0nHOz9I+KFemQtpiZker9U6ElF80UaV+iYP+P34KOOVMJxCQpREEg/Mcw1260bQiMM4+g4jd7IFxRQ7ihyqcBKQbyyNEtlwqfSuovSsra613T+6Lew= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4828e7f-6b73-4f34-fc4f-08de5db1f60a X-MS-Exchange-CrossTenant-AuthSource: BL4PR10MB8229.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 14:40:05.3656 (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: yttVmXUtonGy5m3xzj0ETDNzFzRqiA9CdD4pYBLk8xeny1lCCyGOcPw8Yi1AXHlYvlihPMvy5wwz4cgagHTVhS8VMei4M4007U4uooXy16U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR10MB7911 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-01-27_03,2026-01-27_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 spamscore=0 phishscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2601150000 definitions=main-2601270120 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTI3MDEyMCBTYWx0ZWRfX8VvU3rITTJ4I RvCvto83FyV1dBObQGUPZsm3CqG2toUCiPC0dZY/voDIwdCXBWr+cmTH6o1e7sib0F3mhd70pBm 6yrkLZy5F6iJdtS7ro9zSj7P1fyJrl5mPOKOeT2VdozehCAJZZRvViwe90coeI63vbG5tApCVe9 VX42pILfo+h+XR1lEVGWgbyreA08ETT0alzb9d2AkUT3gUL9y+eZo8SKpMRwgZjYo3YGwROoTcU 3CZv7CWeImIA/6jLIGVsvp3YMk75qtXL+eYSR8ptrjx214NmgydwPZuSY+rh+VJ7ileZ8vUHdaF RbBBbWbWmqz4FJk+lgFhcxVR59KmBUazmwQgXHoQm9GVd5EYLfxF8ILc6+OhTseeD+uqI1OCCEa VzSVaexapSmqu2/dXbhyyqoKRYgeUSSPI+6jSHhI0QWbGSYRMXbqHWpAhpDzcg9TusgF8CVt5s/ V8i9lHg5X1LFxE978HA== X-Proofpoint-ORIG-GUID: _lNPEuI5Ff0R5xDX9bfHSXQjt2_XN1Ma X-Authority-Analysis: v=2.4 cv=Rp7I7SmK c=1 sm=1 tr=0 ts=6978ce4f cx=c_pps a=OOZaFjgC48PWsiFpTAqLcw==:117 a=OOZaFjgC48PWsiFpTAqLcw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=vUbySO9Y5rIA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=yPCof4ZbAAAA:8 a=apGOHuohqZo4d8umOQEA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-GUID: _lNPEuI5Ff0R5xDX9bfHSXQjt2_XN1Ma X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1BA5DA0009 X-Stat-Signature: dd4jq577srd41xxbegcrtfm8z947u53z X-HE-Tag: 1769524842-447034 X-HE-Meta: U2FsdGVkX19DApv1XFoGbMboDDyl113B0Er56XCSRGMw9i7a+9+vkhdf0SuaIeeJ3gWg2nhrt78ZHKH5GjDv4I5Hi/UeJREFKz6in9uYnFYc4sS9p9Bi7VgMypcnLRXOmpHVxJzk3zQNlRJT5H18pGn16OhUYRRq/i/Opd25AHjwDij6vas/YtaXSu0hIXqmLQmZ8H5Re1n4gmEC9xGN+RhQhB9RhB57jB71feOmEcH/8zNNch+wwqzbxGPyHBCrRDLH+6L6+hQicJZSuEWpbir3x0GGZIqVX0yN+c8DCNBMW0lfJDNbt1wv5K8uqlCyk1HJ+mjHsQ1gQ1Am/Ba0kI91jr7rOsF/llLHQcbZOcN+bZzssVXYIGG6IWNChlj26wWZ5QfezfTtZkeL75vEZXoE+jPmiIlejQ06uhA4td5WRNW9Mv9gHKPkEThrEWb5/U6HGxoCdCGK7+5g557mdXi+GaHXgk0OLJBihpLtiztdEyDit2I4B+H5o5GegxZLVug8V8RWNxqJbcQwZ1lD4qIfgZZfa90IIITfKbO1ulUshGDVCn+XN4tWWzOL8UlpEyOXwDxVwcyjy8ReFMRNNMf1s0M0G+4WZsGooPlKss+qg3A+5S8bNxPu68qckRagSrkPmzXZDuV3SIAAtYipSgT9/DHxpeyJv/7vMEmefzx4SwE3aHPpGQJ9Jtw9whb5R26u8gUnoI/J+aQzrTWU3hrVqZguEfLWFhrtD4l2bpFYMBN6vRQILR0SE4ucuCHhHdtTqHP7Ozsik3fFqVieTyo2z0eq3JDEax7QLlq3cd4MOf6o0WNXbx/YXtj+rqtuVWt4SWWWKR9W6LyZMwXlam/OG4OO7y408aktgGrJHE/Z1sDFIfJEeSlxATyRv5hXKvNRgK96coaNpup1w24XosLtFl1rI1bCJzj6KU/b+FS27gwC68jEnGCCffD8HBOr+x8LM65qz1pu0yjuQ4I 7afcmoOf TZGX2uLtRhKMgWloUWXaNUyaN9w3aVGBoOSrVLgDBN+szxZGRzl0/xUsw/rOodiQdOAGomHdzRfaF0xrme4XKayDJNbmwMiYUgSBetTqyrZ3GPDguQmx/8tZ0aOW42/y4x0QDiQznR01dyt8818p3KGkf/b8rVJptYaixR4pS7iEkOYeyizuvvy6LtH6Ln8KchrW36mpeBc7wztPkrLMuSyGVA9S4Sb2C02w7SYh6zvg+xSRlxlCZV08YJuB0EQ5MUISl1N7Plcbo6cwz0zUM22sdH3u3ve0dbmCgjHX59Vp4clHMwdkl/1npPAqyFvsJ1eYvvsP9zcd1ANVb3LXN7nIRo/0/0ZXg3QXe75DFbinxCP+UyMQsbVyGNG0zXMKBSPNA2ePMQaRcWr4dtY1i2YX9jX0WGocPwrd3aFdp1bbie26MJ+7bf50ZsCRj3g7RaFhmcL7TsisSZ/CznyUKSUku8MMP1hHlQ6Ml/U2oqQlPWpDadTYO95smouRPcqpHjxQatkltYb3VvboGRNY3L3Lj0x48iDMv4Zt2E1cfyF7N6ctd8F5J4/xDiGWW35l7lpejFZE6Yty8scX3KVAq0jOyyZqbWilcs8NVo7P2QIhulUSGDBM6KTlUzwuaQ0VzEqHbr539cEHcJR0sCJjviGfsXWKeuAPOC4yCWf+S0Tf8jYxrduwaI1ZPObMSeuuwFdZ4iXAP+Igk3xFZYgahX23NqxqGwGd7tZ1iFSMTcwUeukAiU9fFaD6n1w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 27, 2026 at 08:53:44AM -0500, Yury Norov wrote: > On Thu, Jan 22, 2026 at 04:06:09PM +0000, Lorenzo Stoakes wrote: > > We introduced the bitmap VMA type vma_flags_t in the aptly named commit > > 9ea35a25d51b ("mm: introduce VMA flags bitmap type") in order to permit > > future growth in VMA flags and to prevent the asinine requirement that VMA > > flags be available to 64-bit kernels only if they happened to use a bit > > number about 32-bits. > > > > This is a long-term project as there are very many users of VMA flags > > within the kernel that need to be updated in order to utilise this new > > type. > > > > In order to further this aim, this series adds a number of helper functions > > to enable ordinary interactions with VMA flags - that is testing, setting > > and clearing them. > > > > In order to make working with VMA bit numbers less cumbersome this series > > introduces the mk_vma_flags() helper macro which generates a vma_flags_t > > from a variadic parameter list, e.g.: > > > > vma_flags_t flags = mk_vma_flags(VMA_READ_BIT, VMA_WRITE_BIT, > > VMA_EXEC_BIT); > > This should go on the bitmaps level. There's at least one another > possible client for this function - mm_flags_t. Maybe another generic > header bitmap_flags.h? Well as the implementor of mm_flags_t I'm aware of this case :P mm flags doesn't really need it as users were already using set_bit(), clear_bit(), etc. and don't often set multiple flags. I also would rather not make this too generic at this point, I explicitly want an opaque type for describing VMA flags for type safety even if underneath it's a bitmap. > > > It turns out that the compiler optimises this very well to the point that > > this is just as efficient as using VM_xxx pre-computed bitmap values. > > It turns out, it's not a compiler - it's people writing code well. :) > Can you please mention the test_bitmap_const_eval() here and also > discuss configurations that break compile-time evaluation, like > KASAN+GCOV? Ah I wasn't even aware of this... :) so thanks for the heads up and thanks to everybody who worked to make sure this was the case :) That's useful information re:kasan,gcov. And I see you addressed this in the test there in commit 2356d198d2b4 :) If it makes sense to you I'll update it if I do a respin, since the Link: to this discussion should provide this very additional background :) But I have noted it down to change if/when any respin of this happens, if that's ok with you? In terms of impact, well users who are using KASAN/GCOV are already asking for performance impact so it isn't too egregious. > > > This series then introduces the following functions: > > > > bool vma_flags_test_mask(vma_flags_t flags, vma_flags_t to_test); > > bool vma_flags_test_all_mask(vma_flags_t flags, vma_flags_t to_test); > > void vma_flags_set_mask(vma_flags_t *flags, vma_flags_t to_set); > > void vma_flags_clear_mask(vma_flags_t *flags, vma_flags_t to_clear); > > > > Providing means of testing any flag, testing all flags, setting, and clearing a > > specific vma_flags_t mask. > > > > For convenience, helper macros are provided - vma_flags_test(), > > vma_flags_set() and vma_flags_clear(), each of which utilise mk_vma_flags() > > to make these operations easier, as well as an EMPTY_VMA_FLAGS macro to > > make initialisation of an empty vma_flags_t value easier, e.g.: > > > > vma_flags_t flags = EMPTY_VMA_FLAGS; > > > > vma_flags_set(&flags, VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT); > > ... > > if (vma_flags_test(flags, VMA_READ_BIT)) { > > ... > > } > > ... > > if (vma_flags_test_all_mask(flags, VMA_REMAP_FLAGS)) { > > ... > > } > > ... > > vma_flags_clear(&flags, VMA_READ_BIT); > > > > Since callers are often dealing with a vm_area_struct (VMA) or vm_area_desc > > (VMA descriptor as used in .mmap_prepare) object, this series further > > provides helpers for these - firstly vma_set_flags_mask() and vma_set_flags() for a > > VMA: > > > > vma_flags_t flags = EMPTY_VMA_FLAGS: > > > > vma_flags_set(&flags, VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT); > > ... > > vma_set_flags_mask(&vma, flags); > > ... > > vma_set_flags(&vma, VMA_DONTDUMP_BIT); > > Having both vma_set_flags() and vma_flags_set() looks confusing... It's a trade-off against readability. I don't want these helpers to be too long. Yes it's possibly confusing, but I keep a consistent convention of [thing we are doing action on]_[action]_flags() and when dealing with pure vma flags - vma_flags_[action](). You're not going to run into issues with accidentally choosing the wrong one - as it's strongly typed (well as strongly typed as C gets anyway) so the compiler will catch mistakes. So I think it's not too bad this way. > > > Note that these do NOT ensure appropriate locks are taken and assume the > > callers takes care of this. > > > > For VMA descriptors this series adds vma_desc_[test, set, > > clear]_flags_mask() and vma_desc_[test, set, clear]_flags() for a VMA > > descriptor, e.g.: > > > > static int foo_mmap_prepare(struct vm_area_desc *desc) > > { > > ... > > vma_desc_set_flags(desc, VMA_SEQ_READ_BIT); > > vma_desc_clear_flags(desc, VMA_RAND_READ_BIT); > > ... > > if (vma_desc_test_flags(desc, VMA_SHARED_BIT) { > > ... > > } > > ... > > } > > > > With these helpers introduced, this series then updates all mmap_prepare > > users to make use of the vma_flags_t vm_area_desc->vma_flags field rather > > than the legacy vm_flags_t vm_area_desc->vm_flags field. > > > > In order to do so, several other related functions need to be updated, with > > separate patches for larger changes in hugetlbfs, secretmem and shmem > > before finally removing vm_area_desc->vm_flags altogether. > > > > This lays the foundations for future elimination of vm_flags_t and > > associated defines and functionality altogether in the long run, and > > elimination of the use of vm_flags_t in f_op->mmap() hooks in the near term > > as mmap_prepare replaces these. > > > > There is a useful synergy between the VMA flags and mmap_prepare work here > > as with this change in place, converting f_op->mmap() to f_op->mmap_prepare > > naturally also converts use of vm_flags_t to vma_flags_t in all drivers > > which declare mmap handlers. > > > > This accounts for the majority of the users of the legacy vm_flags_*() > > helpers and thus a large number of drivers which need to interact with VMA > > flags in general. > > > > This series also updates the userland VMA tests to account for the change, > > and adds unit tests for these helper functions to assert that they behave > > as expected. > > > > In order to faciliate this change in a sensible way, the series also > > separates out the VMA unit tests into - code that is duplicated from the > > kernel that should be kept in sync, code that is customised for test > > purposes and code that is stubbed out. > > > > We also separate out the VMA userland tests into separate files to make it > > easier to manage and to provide a sensible baseline for adding the userland > > tests for these helpers. > > > > > > REVIEWS NOTE: I rebased this on > > https://lore.kernel.org/linux-mm/cover.1769086312.git.lorenzo.stoakes@oracle.com/ > > in order to make life easier with conflict resolutions. > > Before I deep into implementation details, can you share more background? I'm surprised the above isn't enough but the background is that we currently cannot implement certain features for all kernels because for 32-bit kernels we have run out of VMA flags. We are utilising new VMA flags for new features which make them 64-bit only with annoying checks added everywhere to account for this, and there are a finite number avaialble. To future-proof the kernel we want to be able to adjust this as we please in future. > > It seems you're implementing an arbitrary-length flags for VMAs, but the > length that you actually set is unconditionally 64. So why just not use > u64 for this? It's not unconditionaly 64 (yet), it's currently equal to the system word size so we can union this with the existing legacy VMA flags: #define NUM_VMA_FLAG_BITS BITS_PER_LONG I'll answer the 'why not u64' below. > > Even if you expect adding more flags, u128 would double your capacity, > and people will still be able to use language-supported operation on > the bits in flag. Which looks simpler to me... u128 isn't supported on all architectures, VMA flags have to have absolutely universal support. We want to be able to arbitrarily extend this as we please in the future. So using u64 wouldn't buy us _anything_ except getting the 32-bit kernels in line. Using an integral value doesn't give us any kind of type safety, nor does it give us as easy a means to track what users are doing with flags - both additional benefits of this change. > > Thanks, > Yury Cheers, Lorenzo