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 5CA0EC83F03 for ; Thu, 3 Jul 2025 16:15:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D02356B0246; Thu, 3 Jul 2025 12:15:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD9B06B0248; Thu, 3 Jul 2025 12:15:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA1A46B0249; Thu, 3 Jul 2025 12:15:34 -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 A987A6B0246 for ; Thu, 3 Jul 2025 12:15:34 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4ACCE802C8 for ; Thu, 3 Jul 2025 16:15:34 +0000 (UTC) X-FDA: 83623453788.30.5CCE261 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf15.hostedemail.com (Postfix) with ESMTP id C57F1A0008 for ; Thu, 3 Jul 2025 16:15:30 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2025-04-25 header.b=a9l4NC29; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=dgGspZ9s; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com; 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=1751559331; a=rsa-sha256; cv=pass; b=G29IdBKgJxpJQ7dgqWLhJoT2iZnrOPBfTPIWs+qF1U9QW+YNsdjjSDnt5WT5qyk0Q0jkId ALykC8+UO+vFCtzaJnEQgcvlFv3vG3fUlWoPeSf/iGL0LXZT2t8egn5oE062pjdbN5ZM18 75P8jB+fhQ95D1jPPsciH8z5gqiERIs= ARC-Authentication-Results: i=2; imf15.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2025-04-25 header.b=a9l4NC29; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=dgGspZ9s; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com; 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=1751559331; 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=+Qwbf96LUeLBAN+FZh+oteLrDuwcR1CIkTX8uArRQHg=; b=UZsOis37aJW0+w2STKO3XAPUzorph0OIihK+RlNAwlMVUmPViy22HSOI0zVFxoAh9SQBqp sJBgAlRSTgF/gkqCdQgFDdjpjK5GSgT0a7bP2tSKdUGytxTbullObPza/c9mQXvrplEj/c 8ZH5qAwSQXZSSw4gH6ILpapLBiNEO78= 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 563DZ7ju029177; Thu, 3 Jul 2025 16:15:20 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=+Qwbf96LUeLBAN+FZh +oteLrDuwcR1CIkTX8uArRQHg=; b=a9l4NC29YSuwF9gGIb6aldCW48hqQi//TH VSqQa+vLgLyTKgRDLY7iL4GCtHTzrbv33n8x9tpgt4xaUNRxGihGqkq0bGC7+Tfi PTnd1E5mkmC7XOJ7+RCOnb4qt0r8VwxTHSBD6G0sbH0+KDyWuT6cNEPbOBupcjp0 fCRD4hokGHH5GnOw4zQ8cKcXhuAVDtyCS9OISbpciUE4GTA1Gi3+Ve46vHR69Jhq ZDZdScGhu6eQPYnosARlY8UtXagZy+9jcPQjiqyR/zeM6L9XvlPQ+ywkYKbmaFE/ RmWMKRfIMG2weuZ8dSGaFRI1dRpuu50juMfrqRBPEc/cahMhfaCQ== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 47j704hdua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Jul 2025 16:15:20 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 563FEQml025010; Thu, 3 Jul 2025 16:15:19 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2055.outbound.protection.outlook.com [40.107.92.55]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 47j6ucw59k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Jul 2025 16:15:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vbSwcdJcDOc0fokskz0fIfXd+0nLx0jfJCa2rlyr0oKyPRXnhJ/tfYwm4SNaqI7imjEmC5MmpyHJxM1f2uKx5Zk+Fc9lJmxIcl+RZmLhF+ZahYxd70kmFozQCkV7HFNzg84/6mm0L3oElIWetZv9/cd9+fincMQhttE8UM5FAhoJQlPTT97Brm0b5fLHJDHb37aJvj4AbirQZBxUrzjXG2e/xoVwf28Cvr2KkWmTr2hB5D2CKsfREd1cgdFpvV0Xg/zxzXMyOzRp5mexAUvFjUBppPH2V0sIO+3M3ENimMNmjX8n2KkxfwylXTutUfD91wJdUvVLoi3m9qTIVkzvvA== 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=+Qwbf96LUeLBAN+FZh+oteLrDuwcR1CIkTX8uArRQHg=; b=XAnNiHE3T8hNrEM2jwPqMIPmP5IVTn4VOudQ1gR/p4XCjZvwIEPI/HOxsOQbu0Ib88BOsH4+kNE14nTVFLwqcznRo/OGPZ+dUqUD3pzS9N2xCKNSI8NK631cP2mRFFyBZ5lSGA8cBrsk0g1ecsDbrMjNl64O6U+/2cZttLZ4ifbw/qR8hVFSUS+MFKNvE97XpLwOoKEWKrmd/gbRbmrMxrqMqSfxD1QiU0C2ctNc7bZ646n91jaB5ey+8JhGNDSIbQHVy97tkKKW9hcudm2DRwE2KQQgcSjbG+AwpX2ebsDziHAOG7FTet6fR9V/jsKMvl5tDGvgAISMWipvu7z+mw== 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=+Qwbf96LUeLBAN+FZh+oteLrDuwcR1CIkTX8uArRQHg=; b=dgGspZ9sJfitzVO4ev8xrzxjm5MH70Pc1jLhRMdzLgI8vB7CKhWf0stvapUNt+SAFsApmBIt8m+Yrr0eXFIINfHPIoBuf6vjM7gOBm51f/+XL6P+2pmwiY1W6xFNkYwa0599vuZxM+tw7H4cEjI8+wCfj57DQ6dlndvD2Rq9EbQ= Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16) by CH0PR10MB5115.namprd10.prod.outlook.com (2603:10b6:610:c4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.22; Thu, 3 Jul 2025 16:15:16 +0000 Received: from DM4PR10MB8218.namprd10.prod.outlook.com ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com ([fe80::2650:55cf:2816:5f2%6]) with mapi id 15.20.8901.018; Thu, 3 Jul 2025 16:15:16 +0000 Date: Thu, 3 Jul 2025 17:15:14 +0100 From: Lorenzo Stoakes To: Peter Xu Cc: "Liam R. Howlett" , Nikita Kalyazin , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Muchun Song , Mike Rapoport , Hugh Dickins , Andrew Morton , James Houghton , Michal Hocko , David Hildenbrand , Andrea Arcangeli , Oscar Salvador , Axel Rasmussen , Ujwal Kundur Subject: Re: [PATCH v2 1/4] mm: Introduce vm_uffd_ops API Message-ID: <5231b96b-db1c-48b0-987b-736bc90843f9@lucifer.local> References: <20250627154655.2085903-1-peterx@redhat.com> <20250627154655.2085903-2-peterx@redhat.com> <982f4f94-f0bf-45dd-9003-081b76e57027@lucifer.local> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO4P302CA0045.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:317::20) To DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|CH0PR10MB5115:EE_ X-MS-Office365-Filtering-Correlation-Id: b94ae281-ac63-4e0f-0050-08ddba4ccc69 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?tSKWV8vu4E3buXe68cLxqhOzrfMPGgEmx5zuEipmTaPCbvORZKMnpn8e0vdb?= =?us-ascii?Q?fhhXquDBGlswJ28F8xYtUez9p+9RKo2jYl50nEANLBoBXtnsZYzs2BpgU6m3?= =?us-ascii?Q?HHfBYvRfeQG4l5o3YCvNycGZT1SM7HWGTF/zSdXuR63W9O6YRshtFVC6buuR?= =?us-ascii?Q?iiMBdQlf85/cSTszej4RjiQTSah+UPSRHaCPlo9uoyPOfCcbeH7AyvbrNfnF?= =?us-ascii?Q?qgONRHHTUj2pD5hqY1cZqMFHnN1LQ2PntJPYDRwlmN+6reDd4Fpb2VwSvS1j?= =?us-ascii?Q?CyY3DA9/mKECS3s0Kgl6Drkxub+6n1WDZk5fhsb85PpKEDQui6fZHDBjmMxh?= =?us-ascii?Q?82c6nMlKh8D0pkjuZagEGbtkP/LxOrqO5bN0QWedR5qlo5dPpwWr3XNx27hd?= =?us-ascii?Q?Q7o1WjNB9DmSHEb2LyxEB1tLorsT5/3kcAXvntKbKRHDLtfIsPsHjiyJcY2Q?= =?us-ascii?Q?90VEQu3SlN/S562ZZoWgoQH2l8dYVmj5HwZdvkff2E7vKu6j6Tt0uGhBzjEw?= =?us-ascii?Q?xgwLHL/xEOf9sJIB+8TNEUImOmkdw7hQuT1QHYJEEEM1tmx7bZao2d2fDr0Y?= =?us-ascii?Q?y6QEzsrTZ636vmJtSxygryuEoQm0RaX5ORMDZyhWczqLBDLrj91JCXvc1qUZ?= =?us-ascii?Q?By3dsBsQy/7MarztljoBwlrfqgdrqHYJqwhBq3omf1zWchqIWp4Rqm2BiSYP?= =?us-ascii?Q?F22TygYlEXEkE6ke96LeAJQ2xkCQxG0XDwB0+3aCiBcqLWvJiknCLUobEvzP?= =?us-ascii?Q?98nQngim3SdIkD0HrZz59zp5skf/9Bg1WyyVuijR1FJqHZPEQFG515jysNqI?= =?us-ascii?Q?so++Egq6OHrIT3yiDDIsGSUjhbck7yUTd56tnKvOS4/y3zjNB3ae0yJibiCD?= =?us-ascii?Q?ZYU5omJhgJtiaFznkhW/a7BFYPBiluLP1FLKZ+YvHePSBt31xJnZq16CPqiD?= =?us-ascii?Q?T/huQq/dsPwpbEKmxVgu5o6tS9jPoPeFECdMB1e9IU2oHix2uWVCWxY0j0Vm?= =?us-ascii?Q?z3+KYjZzIFeJP0cSvwF+/cg0kfA8cz871VgFGyk5ZspI1BFm3oviiVzRgM8z?= =?us-ascii?Q?Uz+3LXJ03LLJLdbbNPuJaKS5d0vvCOT3xNYuGUAkBNvdqzFzEaWDSAe9shLp?= =?us-ascii?Q?hQj/llYiLxuf56VvZ4qvToohMPIHmy23qe2jbOjaNmQuTpteJmWzgSerrSLD?= =?us-ascii?Q?RzF4m0ZpN2C9+dns9JOagvmqlacKqAFRjDgwGqXyffVfDxkQ7oZ+B0KEV8P8?= =?us-ascii?Q?n5kU0n4Mz7o5gw7B9xP9eZHiY6BTjgEgmDokE1A/uRAUCAxsJFsJhrIBWUiv?= =?us-ascii?Q?xqCRcX6u2zvenaQq+bOkc7H0tMnYbwGtAV/SFlHmbdAhaRwJP1tTw3YRa6Ba?= =?us-ascii?Q?nBWNqgewEJ8cQDd6uSs/8283Aw/iSbjzBzKPaNOo4jghdkj/QZpOIdknXFFX?= =?us-ascii?Q?vgaKSw5Ujzo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ynedsd9TROpveeVd9h082jr6BV9d5zImm9dwm3WlFpqJO/V1lPx/tClin0BX?= =?us-ascii?Q?O1YbC832rPWb24MSvuOq3MUJ75iv0KBnl1tpz20lo1Zim3YcwG9+ul6AoPCb?= =?us-ascii?Q?mdZuVueMaCZppGy5sIjtQvdB437yfQTiV5OqZiaSsHgpl/Qcg8swwWarwVqu?= =?us-ascii?Q?6YNGZTja68xWJ3AU/JpnXWYyfWb2Py8QOTTJGdouOX/yAr0mB5JxUmBoU5jW?= =?us-ascii?Q?M4wNOhZ4tO1iaxTG8WoUusQhjjoUQNixc3+y6v1o3oeehAcr007XMB+XQYta?= =?us-ascii?Q?0P5njAnCrt6zNu7eQ/Eizf4fhKOxrONkhBhfAErZLYZQXJMtI/S93KcVEEst?= =?us-ascii?Q?qDCwtfHMlyUGbwFh0fRbOrNv9czzd20t8o838+hUAlLyY4uzuoJv+dipNRZM?= =?us-ascii?Q?ER48MMq5If8TOFom69ptsz5kqNNjkCaYxDaJmqIbE63mY2Dd5ToHRwE2tDXr?= =?us-ascii?Q?yBO5i5dZu3HZYF15ZRRVA4DBnXiYHqIEVnqk9eenOdb49hIIRLksDatX1is9?= =?us-ascii?Q?PVuph9bzB9WPs15YAyIOeNFwVkrj6ElE2g0sttltw2QjuZitkdp0qXXhEfc/?= =?us-ascii?Q?QQBlQsbowXE72nY8f1JzLXpDP/G7HDL46puDv6XHcbzQTQ+EkSd+syMjGZCX?= =?us-ascii?Q?+JgEXaSiXvcijBdATjba0Rav/5WBhEuvhEpR/BQB7ZqVvglw6zAzIOuJI+h/?= =?us-ascii?Q?GjSAXQr1Y+ixpSI7Ibkr1z3ogdhNsa3fMHCrHk6dq5N+3hPFkL9yycfA0KS3?= =?us-ascii?Q?zvk3GlVnoGSDXOigbSMoCt1sg6tim2t7LaRvMox3cFxHiI7OWAMctI141WWZ?= =?us-ascii?Q?XQP7tu4Q5EPR5p1dIXfdr1bOXEO9ZM9b5yUGC+oNCEisNZGs5BS/exq2u/ih?= =?us-ascii?Q?YLWqPvYYK//uKXlO1d063kj6k3fKnzYikECOJ9lftjPjjQF0tX0LyzsZz06J?= =?us-ascii?Q?RZ/r5l0vYOc7huExuKfNrlTidcCM2FdGcrLHhv75lbHsD7cPoE7yiukpfjjJ?= =?us-ascii?Q?9JhXayCAlhYgcCwefWJR3jD03UNcS3rPrEpv2Wj98iYz7OXZ3IujLDQ2qHz8?= =?us-ascii?Q?o/OJAWYGEa5KQAhEB0z9JhRhGglRV1RBIKy5PfHPUflFgcgfuZNeEXw6YC0z?= =?us-ascii?Q?pDUvigP0f8mYKkpMJFbc2Xk1dYf25WA6LCUacS7rXoy7VsiqfObcNgpndXWj?= =?us-ascii?Q?eQHV4I8OCd7JGMlI6ZfTkmUOzJ0y0VWil+4d6R6mvXikklmS9OZxBVgnjxW7?= =?us-ascii?Q?BQXQlJG4S0fhppk1naS3xi1ouBJ/9WEdkK5K/41x+H5rb8rqzl+2DO4vu8eR?= =?us-ascii?Q?BGsdmRltDEiUMChqLu7w0oCe2H6o9A2KoLH7E4uyfFzDpZpeXdmD+/9v0Mnc?= =?us-ascii?Q?EkbKER3/h9lApRx/5AFROwZvp0dI+1NpbmlD0CsO5Lwaqd/EzI3FglB2QfnN?= =?us-ascii?Q?ls0T0t0RCCCR5cnE3UVKDAKdUVc7HkgAOBnbvppdrWO4QGx8bLzZcbhta2x0?= =?us-ascii?Q?xKdcpOG7J1Mzh7gzcwpdFMIIUmZfX0X/TAorH43gsoG4xPHRIG9469WICofE?= =?us-ascii?Q?UdwBoiVJkxu5Z9In/N4+kW0XnzOVpzR5CucYz2lS30vyrrklnr+1z5GDQ9vl?= =?us-ascii?Q?/A=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: ZX5FCUp9YQC5XRBIMWh82NaxtChUf7BH8PuWl0eNmtBDOVN8P7UmPJ6BuhpstJHACC5/GF6JyWQxfH6fLFi5jx+qdj+GUGqucqV+loDoZPwE7T2/7YYvO03y/YvFAgUYZtSd8FjoPW2KSXeHSO8HspNH4H7kIkI/kK8iXouJdahwQ95F9DsKnlJaewPwfTXzPi3U80aQEA97l1sA8DVTi6ALGWNhaVUxr/Sd1YLh6US1h5V8n2FnWFadcqb+i28sE71RcNpJIytmHlB9JNei6505TdXl2J42n81LP1BvI+GGtG3lKE7+htKgDkAOBpLeh9CNC/onnnSVCAmMSXQybCSl1BXGRtS76fUPoiR8fmG42wQx+94FYRKYkBJ6e2vSebXYx9iSqxxQQraYL+FKWe6gsVjwpz+alC0/MrrEb6XqXoq79yHBp1tRmFR9cwRI5UK0Q3WOXsp7ErTvlwuKf+MfnztCT0kg2POQcwDMYms0oilVfXz8UTqLGLUZq+atUxHAk6jwII+i29fpfHs0z1Njk7eCwDXNaO01QuzMxIufcULbXagOgIW3ZGpJJrCZIngUi04523QOHPdB2tfGBpoqiz9PAT72JpM+kj8FFXM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: b94ae281-ac63-4e0f-0050-08ddba4ccc69 X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2025 16:15:16.6963 (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: hczRMTiK2n7jeZkkeFFcw80H/jany06xa7YY8DKO66po7uGQ3pG2tFtkl9Ub6M5Ukgfn5IgTuliuILaoGMCSGmeBgsnmQ84g4C908XDe21Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB5115 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.7,FMLib:17.12.80.40 definitions=2025-07-03_04,2025-07-02_04,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2507030134 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNzAzMDEzNCBTYWx0ZWRfX4ImrXahqQmew rYgQjZyoXf7JcsiWD+WYMarfDQhc4ynlNd5ehUGrLA2Q8P61x8M9PDAnvBmuH6nOl3KxrQE+QEq 1R4PHrkPvmuzX3G0doA5QQMN4vXsvpIh2u1s4k1qHLVXEeJ8OPrJSjANXc5KyXHeb6vtXMSII/u +mYx2sGF4qI8vrw+U8YGsqxUXUoCwwlIlcZmklY930uNx+NP9TivCtUFjDNhDCRFJ+N4wnTwxzt y8lrmppWmY01A93XP/8S8WJVmb780vFPn5RAN2Pif4YRExTNy5goDDcYqI/Oh1m8ZA+G9iH5M6p EHcNwTmHxNrpXJhgmn/5kZGAuBcCsm7tAYlpt6DLng3nFM3KLM5OHH9fFdhFm49FQDsOTsd7k9v RDHmp0RPDXYGSvoMmitIqPe4hDBQDozjfDRfs0fcc67zBeZdtEZaYiwMWduE/vuQRoBPGpin X-Authority-Analysis: v=2.4 cv=LcU86ifi c=1 sm=1 tr=0 ts=6866ac98 b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Wb1JkmetP80A:10 a=GoEa3M9JfhUA:10 a=VwQbUJbxAAAA:8 a=20KFwNOVAAAA:8 a=LY4zg8RYbgwotNJ0-7kA:9 a=CjuIK1q_8ugA:10 a=gmshbCpD-_wA:10 cc=ntf awl=host:13565 X-Proofpoint-GUID: i44_gqwWA6ilIUujlNK30unRR3CClrYN X-Proofpoint-ORIG-GUID: i44_gqwWA6ilIUujlNK30unRR3CClrYN X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C57F1A0008 X-Stat-Signature: b1ayqtp5scgpyaoixw8hn5npahgd87nt X-Rspam-User: X-HE-Tag: 1751559330-913599 X-HE-Meta: U2FsdGVkX1+UKiVBxtLg6ZYOzKPbHDSd7fFX2Bugl5srLd/B5lUUnsESJ+a6LRK+GUvW9/HXMDE3eIwGjuriBh2aR2oLfMcBUFk/9pQmSuSnLgHC9uu+HX50oZfSda0y4L748yImLULf5n7hYmc6nDvfO4Wkw1sIQB40cmyzJJGBnlzunG+HC0B4ce4u4nuzInJeuhCr0hDKf3/wbQakAGxuOBI5KSjRTg6N8IAfpdmO4Sj3+tQHlwArHTp+b/BIplLayn4JjsaimLLQ21Cvdt3gpkRUriLFHiTIa+HNUBMkWv0rgaK9uVvbAp+AqSx/lYlVROVJSEYapnVtJwyRn6jPR3Vz9auvR2qZF/mKmYuXdlELJPrHfHLEfqDDdpzpaxS6SPAuvdm49wNLRn64+uXphY6Erl/QHkihtTIWsvK0iwc9ytjSQn+COqIxT2xp9fYwLyrryZedPTQ95az0RiYddCC+TwXxj1giMz6OVuZ5dKW1EVDlgPI91gnPjHGR4AxhHIcbecSuqZ1NeBw4Zc6K4DWZxcZgh9Uc0vuUK9u/2nEOK7uE8x2LsKCh+PA5x78aPh9QfjdLW8yU9H4jLT/APCjz3xbs3CQXWssX5XjtZCNAFP7mizy+cxmbcV6chEbMQkIoO37h9NqytFfYwim+RlZt/ugcinRP0DXJeY3nTWVKkINQw1stDxVhzVKU+099Er4mM6116CRJ7ss3tiGZ09q6rJQw5Z2upClE9KEcgpMd9XZ8exK7MEhbShRnrQTOnFS6jni8axw5PfaEqGXmNqt4R3beec3w5YJRYzC6mOG+6SToDxUEf0NV9wr+NKp3MaY8CYCwa1j38oH5tPXxOAMJ2m/ZXsTW6oRpA6UC1M+/mxgwtUOo/8grb3q1H2m6EWBcpLL143DRfWcaGAUyz+Rzc5IQ3p+PWKS7BnR0i9iBbaTrllYeDtShrGjBJNPItiSzpapWGDxWNCC 8/jkFsY/ 6qvD5tUGYSO3kxMtGwkhkHcg0tr6SBW2sz9kXXghGmudxy6O8gwS9C8ccmE7vrkkAwwTuDL+c11CXfvWiQlKlVOsOl8QBBuWSb85ZoscJR7bNkcSFMm/h0QnQzOW1uCtFvQvBZ1wFT8oXOnNHIQBxZlKMXO9biotlRmFuQ2IenXFpp/5na1k8udEzSWlDPHgsoBGTSvEAgi9+8e9YWC+tsD7y/4A/7/uhryoJjRvdXsjDWXfxplEEXMT4wunUbZMRdnvh1R75n5vwS6zqbK5nuaK9QkscHCLqJNgBXY0rVPB+dEF0LvryNQoVqkLkI3Ygs/sjlwFIYyjQSASLXV2lD6ql4hLjr3Cjgw4/U+0iK3KDiNwxehi5gDlgx+xYqZ9qidxQTfJ+5jePqaHqgrEIJ3k+ujfiwwbOJVgjMzMtU1JvVQ4XjUOnkRURgQnyWc0mI8muWP/AJoD0fJqxoJYOzFW0DCM3QCpvmFDCi5DHl/0HqeXF//KwjXs6z4pR9dRGOy58r4SWGqMBw08xCFc2rtkN0grHS5nsWbudHFiCeumnPdRTSVCUQ/UeB/xgo6/41rOyG4lVMwAtLLHTq46VmpDywm144AjpwQ76+DHld5Tjekm3mHA8+XOuJkeiaQmHym9Q98lcw3ts/Y3Uy1PguH3uq1PE67FN96Ic3OhO4VbW/ktqoF9h91oulbNTsXbdl/eXw1iGHgOjUTCCIHGGX0GUXCZYwlJ+S/S9w3z+O9gNKnwWLD7DHWn74TTlr+/lDLeaLmAk2Fjdep9VWG8SKIODhYZJSXqjSE5jQtk/rNo2K/YDn5VsB2lGBsnimIA+w7N1dAPdaoiB46c1BqcbHkE3foH7rWeHyZ2TXe9D3JAGwuGmH9cNOLq66dGIZEg1GWaUKqqtT0YSXaHYnkASNbhEgA== 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 Thu, Jul 03, 2025 at 11:24:21AM -0400, Peter Xu wrote: > On Wed, Jul 02, 2025 at 10:00:51PM -0400, Liam R. Howlett wrote: > > * Peter Xu [250702 17:36]: > > > On Wed, Jul 02, 2025 at 05:24:02PM -0400, Liam R. Howlett wrote: > > > > That's because the entry point is from a function pointer, so [3] won't > > > > help at all. > > > > > > > > It is recreating the situation that existed for the vma through the > > > > vm_ops in mmap, but for uffd. And at a lower level (page tables). I do not > > > > want to relive that experience. > > > > > > > > We are not doing this. It is for the benefit of everyone that we are > > > > not doing this. > > > > > > Is the vma issue about "allowing vma->vm_flags to be modified anywhere" > > > issue? Or is there a pointer to the issue being discussed if not? > > > > The issue is passing pointers of structs that are protected by locks or > > ref counters into modules to do what they please. > > > > vma->vm_flags was an example of where we learned how wrong this can go. > > > > There is also the concern of the state of the folio on return from the > > callback. The error handling gets messy quick. > > > > Now, imagine we have something that gets a folio, but then we find a > > solution for contention of a lock or ref count (whatever is next), but > > it doesn't work because the mm code has been bleeding into random > > modules and we have no clue what that module is supposed to be doing, or > > we can't make the necessary change because this module will break > > userspace, or cause a performance decrease, or any other random thing > > that we cannot work around without rewriting (probably suboptimally) > > something we don't maintain. > > > > Again, these are examples of how this can go bad but not an exhaustive > > list by any means. > > > > So the issue is with allowing modules to play with the folio and page > > tables on their own. > > I understand the concern, however IMHO that's really why mm can be hard and > important at the same time.. I feel like you're dismissing the concerns altogether honestly. > > We definitely have driver code manipulating pgtables. We also have folios > or pages that can be directly accessible from drivers. 'There's already bad stuff going on' is not an argument for doing more. > > After all mm is the core function provider for those and there needs to be > some API accessing them from outside. The point being made here is what are internals and what are not. We don't expose internals, we do expose a carefully controlled interface that minimises risk of things being broken. > > I agree some protection would be nice, like what Suren did with the > vm_flags using __private, even though it's unfortunate it only works with > sparse not a warn/error when compiling, as vm_flags is not a pointer. > OTOH, forbid exposing anything might be an overkill, IMHO. It stops mm > from growing in healthy ways. I'm not sure what is healthy about no longer being able to make assumptions about what code does because hooks are being invoked with drivers doing _whatever they like_. Part of the purpose of review is avoiding making decisions that cause problems down the line. > > > > > If this is outside the mm, we probably won't even be Cc'ed on modules > > that use it. > > > > And do we want to be Cc'ed on modules that want to use it? > > For this specific case, I'm happy to be copied if guest-memfd will start to > support userfaultfd, because obviously I also work with the kvm community. > It'll be the same if not, as I'm list as an userfaultfd reviewer. > > But when it's in the modules, it should really be the modules job. It's ok > too when it's an API then mm people do not get copied. It looks fine to me. This is ridiculous, we expose mm internals to modules, and then no longer have to care when they break things, or a subtle thing changes in mm? On the one hand you argue that in-tree drivers can be 'monitored' + therefore it's fine, but on the other hand you say it doesn't matter what they do and it's nothing to do with us so we shouldn't care about being infomred of changes? These two positions are contradcitory and neither are good. > > > > > We will most likely be Cc'ed or emailed directly on the resulting memory > > leak/security issue that results in what should be mm code. It'll be a > > Saturday because it always is.. :) > > True, it's just unavoidable IMHO, and after triaged then the module owner > needs to figure out how to fix it, not a mm developer, if the bug only > happens with the module. Except it impacts mm as a whole. And it is avoidable, we can just _not do this_. > > It's the same when a module allocated a folio/page and randomly update its > flags. It may also crash core mm later. We can have more protections all > over the places but I don't see an easy way to completely separate core mm > from modules. Yes if modules absolutely abuse things then it's problematic, but the issue is that mm has a whole host of extremely subtle considerations. I documented a lot of these at https://kernel.org/doc/html/latest/mm/process_addrs.html These details change quite often, including some extremely sensitive and delicate details around locking. Do yo really think module authors are going to correctly implement all of this? It's very obvious these are internal implementation details. > > > > > Even the example use code had a potential ref leak that you found [1]. > > That's totally ok. I appreciate Nikita's help completely and never thought > it as an issue. IMHO the leak is not a big deal in verifying the API. I think it's quite telling as to your under-worrying :) about this stuff to think that that's not a problem. You guys have already made subtle errors in implementing the simplest possible use of the API. This just makes the point for us I think? > > > > > > > > > > > We need to find another way. > > > > > > Could you suggest something? The minimum goal is to allow guest-memfd > > > support minor faults. > > > > Mike brought up another idea, that seems worth looking into. > > I replied to Mike already before we extended this thread. Feel free to > chime in with any suggestions on top. So far this series is still almost > the best I can think of. I mean if you don't want to consider alternatives, maybe this series simply isn't viable? I made suggestions in the other thread re: a very _soft_ interface where we implement things in core mm but _configure_ them in modules as an altenrative. That would avoid exposure of mm internals. I really don't think a series that exposes anything even vaguely sensitive is viable imo. > > Thanks, > > -- > Peter Xu >