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 3A9EEC0218B for ; Thu, 23 Jan 2025 17:07:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90955280003; Thu, 23 Jan 2025 12:07:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 890FB6B0095; Thu, 23 Jan 2025 12:07:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 695CA280003; Thu, 23 Jan 2025 12:07:35 -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 42AC16B0088 for ; Thu, 23 Jan 2025 12:07:35 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BB3C6C01DE for ; Thu, 23 Jan 2025 17:07:34 +0000 (UTC) X-FDA: 83039348028.02.6CBE763 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf24.hostedemail.com (Postfix) with ESMTP id 62C7618001B for ; Thu, 23 Jan 2025 17:07:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=Kcfi7CHP; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=nVYnyJXU; spf=pass (imf24.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737652051; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qbV2zFf0BugGNB6a17mLbVPFvkEAdHl44933WriR2F8=; b=kybXg6fNI2rKCQgEspqQlPSvYl5s6+w1aVnqmB2blrR4IkjO0g9OrOBnOAaAnmaQ97jecA ss+5ybnYwmdDNryQK0XWIg3ICCIdIkEQIpub1cJ6w4VwUNgda66B2Whmwy8H9v19BWnAHK NeRYMqKgZwq1aP/W43HeHL09wzTLfLo= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1737652051; a=rsa-sha256; cv=pass; b=6PJGnRxk3QXKc8+1RPLJ0kN5SqDyjy/r9seTISqGQ+V76nSgVDq1MP2aMSOCbQ7XGRrNFI q5XmRPa3sgn5NMHfhFJQC6o8c4c53Qh+HC8Bj7C8G4WRPjKg0H79MT9n8jSiYKpsB6Do44 yyayOViiRJqQzLj0wjBwJ1bkH95MA8Y= ARC-Authentication-Results: i=2; imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=Kcfi7CHP; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=nVYnyJXU; spf=pass (imf24.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50NDaVXk025538; Thu, 23 Jan 2025 17:07:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2023-11-20; bh=qbV2zFf0BugGNB6a17mLbVPFvkEAdHl44933WriR2F8=; b= Kcfi7CHPj0CyC1IidGKu1VYWLJnPbafqCDpxieX5tXNSRQzUHhbipUbe7pm2LiXi RrmKZRaohvG1yfJgCYf/u3wGarSA4tCW8h3kdSuUGgbVJj4L7us2Bng1P4b7K+jQ UO+C9/OHjkQRENiTwvFeFUVYnHGCS6OA9fo7Ml42KeV0qKtH0DuAeCxU47fl1m0N Eqba4fAIejLQ1gw3NocZkcPaAKiKbzxBFfwmZZKtnjgi4QpY+ZgCOrP/Kv2Z7saK Gt/4ZoBHn3EgYcnZYyzZXa3CC30hZ8LQGS5YOPubav0Wjyr1Rk2TQsos/qWxTj4w InutEvj4G+M3w+vqRgjE3w== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44awufu6me-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Jan 2025 17:07:20 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 50NFrRpQ018931; Thu, 23 Jan 2025 17:07:20 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2043.outbound.protection.outlook.com [104.47.55.43]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 4491c57rs1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Jan 2025 17:07:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FUf7SE45ax7zccTu0uVniYCbrYAsRVQP0EDpH4aQl6Gz7Fr6JNEcrS/uV+RqoVIL7cupaWv3T3aCR5V26bLPZEHmD3mDCTaaTjPZ+c/tWQpACo9nxb0+veqcPr46IrpQfcpqFhkwLCLgMTzzkY8Wj/CGpSB/AyTpSjWSeyzysFkEHmLJuDgMP4jsoHBx9xWI038x7mo5dBvoWx9sghZa/S2qF5Z9sMDi/hcKmU8gzFW/HQRHOAsAGptSuCWhQ3XzYzkd1lg9/NPSWMpAqTNJN503BbtsZPdWq/4RncsLmrKD3sG7l5sV+vpYeviRiU2N4hvJqD+1mwhsdRY9qfCmcg== 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=qbV2zFf0BugGNB6a17mLbVPFvkEAdHl44933WriR2F8=; b=Th+aqWD3WUnAXZD5ytb2gpWEZPxIKgdV/gSS5eMSnJrWoSFU+92dcEMGRCFHXe5JVjy0NeUBOpuB3/Rb7SO270VVEvsO3osfKZ6f5c1iU47Sa1/Q+ISEIVFLV2yo9/9UOT7lS4Fz7iHCABUcZft7Z3rpMYd41pohKJ8Jpm/gSfoAtLQ0Z2s4HsNGMIT8Z+QOrZ9w8WTjyj9N0jTUZ6Dbo617kGCaegBrbMl9fH0NGMHbS8Q712I4bJNEJp2UVpHGH1NdLoYp398AKpMMI3iMPhYgVp6Zo51Wx9OkoSRQYieEK5PCg8QT0NIDB6VWabEOO79ICrPWkJeDkHxlkR9JDg== 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=qbV2zFf0BugGNB6a17mLbVPFvkEAdHl44933WriR2F8=; b=nVYnyJXUZy88e3EGB+KbV9MbaxlOeoZtGPjQgh7vfo9nBn1gut7lgbTMmtPmEkUAb5T+C9ucYKBE5bW4EYT1BUT0kgMFccoMRjT+9w5o1IzPxVdPvj/SrPeSZXnIIPxTExgADybTxh9ZSKlqfQyHsYFVj9bIhYKTM4gAbLotswA= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by CY5PR10MB6261.namprd10.prod.outlook.com (2603:10b6:930:43::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.17; Thu, 23 Jan 2025 17:07:15 +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.8356.020; Thu, 23 Jan 2025 17:07:15 +0000 Date: Thu, 23 Jan 2025 17:07:11 +0000 From: Lorenzo Stoakes To: Barry Song <21cnbao@gmail.com> Cc: lokeshgidra@google.com, Liam.Howlett@oracle.com, aarcange@redhat.com, akpm@linux-foundation.org, axelrasmussen@google.com, bgeffon@google.com, david@redhat.com, jannh@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ngeoffray@google.com, peterx@redhat.com, rppt@kernel.org, ryan.roberts@arm.com, selinux@vger.kernel.org, surenb@google.com, timmurray@google.com, willy@infradead.org, Vlastimil Babka Subject: Re: [PATCH v7 4/4] userfaultfd: use per-vma locks in userfaultfd operations Message-ID: <38ce85e9-9727-485e-b232-bb285ea24f31@lucifer.local> References: <20240215182756.3448972-5-lokeshgidra@google.com> <20250123041427.1987-1-21cnbao@gmail.com> <6aee73c6-09aa-4c2a-a28e-af9532f3f66c@lucifer.local> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6aee73c6-09aa-4c2a-a28e-af9532f3f66c@lucifer.local> X-ClientProxiedBy: LO4P265CA0137.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::15) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|CY5PR10MB6261:EE_ X-MS-Office365-Filtering-Correlation-Id: 6bccf664-6e0e-4420-61c0-08dd3bd062e4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UWFhU3lTUGxyODU3N01WRmZYT2M1Z1FKT2FWNjF4VmlYOVllbk9NbVN5dHhM?= =?utf-8?B?U0svQ1Nsa0pwVmZKK3l3VU1jVEMzdlNPb0VST1lnd1JNMHJzWTYrcjQrMVUz?= =?utf-8?B?RktiUnNUbXEveEh5N2MwK2FUODJ2cU5rdXA0aGRnWVlXajVCeXZCUlA1OWx4?= =?utf-8?B?ZHFicWNTOURlbDE5VnJ3MkljZ0dqOS9VVEZwYm5vZGRWRm9QcjdVTTFlKzJL?= =?utf-8?B?QzMrbk94dzRJdllqMXNFMkpUeTM0R3F1N1RLaGtyU21zOFkrRThKL1NpYkRV?= =?utf-8?B?Yk9UTWxaeXBsVk9jbUNydm9JSWdXMHUzaEN6RGN6RVovblJkd1djSTdTc01O?= =?utf-8?B?UDhtODRxRVB2UHBxOEJveEtOMi9aNDhQZ3ZpMVpDbVBMVHNxZnhnQ0tCbGJa?= =?utf-8?B?WTljcFJISkVzK09ianNrb01tRnpoOGVKSG9tMkhVd2FBd0Q3Mm1PL3lqclN0?= =?utf-8?B?OXZKbXJzTDliZG5CTnp3TzBQelNHUm5TcVFvRGp3SS9STFptZCszYWFkSGcz?= =?utf-8?B?d0x5Y3R3Nk1zcXFwV1llMndpbWRnMFp3ZmMyY0dWSmE5WFhCcm9YTnlqajVt?= =?utf-8?B?clVhTUtwZjBUT0hSVzZSWkl6ak10ZGN6TzVuL0MvN2ExbzNyWjF3SE9vdERs?= =?utf-8?B?NXBIMXlBTDA0NGQ4bHhQeHFMc0VDRmtpTEZ2ME5PZGpCelpqNDZ4VWpoNGlp?= =?utf-8?B?S3BvSjVMalFiU2REZ3VOeFV0R0h6ZWVraXRmRkNlQXN1T1F0NGpkZmNjUHJp?= =?utf-8?B?VHBTb21MSkxXdjBFYWFNMXRLQUNXSVBINEpYZUdVUy94MU9IbHRnSmlsYmxm?= =?utf-8?B?STZ6WERkOUxBYXRCdEt3ajdNdDgwQWs3M2NBemFrSFBoR2NHKzNQY01Bbjhv?= =?utf-8?B?dXVaU05hdld1ZVZlQUFzS1c2TkpseUVtRW1hNzA4dlV5aFBCRVhsTGowNEgw?= =?utf-8?B?b0V1NGhCNTBZeGpzYmVGVjJUZk9TUHhXNW1TbWNaaTBVNDhCN3RCWHloYXpB?= =?utf-8?B?bVc0ZU16Ykk0YWFBN0pxczh2T2orYnhaVnZzU2c3ZmVNYVdIRTl4cnR3Y0Fh?= =?utf-8?B?NXBzaVhEeUVPdS9pc0hTQlFyamxrRDRnai9iV1ZYa3p3VlNjbnNpclhmOVZ3?= =?utf-8?B?bkRhMDVXelV6RHo3TkdUQWloRmhXZkhoODMyVkpieDlxMjNGRlFoUy9NTUI4?= =?utf-8?B?UWhXMStaUTI2bGlXMXhEb3A2amdMaENnQ2lkRWZPRzh5Z2RDbnpBS2UxdEdx?= =?utf-8?B?MDhIU05HWU51SFZPT081NnhPNjFTbUhTNmlBbG9ySWhGUGpxeDJLbG5NbGZq?= =?utf-8?B?eXU5TFdPYmI2MjdTeG12MERIOXBUK1lBcko4bjh4c0tQMm5nMWZ6M1hJbkx3?= =?utf-8?B?eXNrVEIxbFoxd1VXVVRnYkZCLy83ZnpIVEczYW84NEptN3VsbFNlaHNMajJ3?= =?utf-8?B?NzdYbzBYbGdQTlY0MFIrNnAyWnhRWGo0SS9RbmppdDE0dkI2Um0yUW5DbVdS?= =?utf-8?B?MStQYVRMODh0QWx4K1RIRmF5M0RPUVZmMW9QUkFGRU5kRXVwZUZ0UWwrRVJv?= =?utf-8?B?ZXU4TjN4amFtNXRuVnpvQXp1VXVEeVdPdCtseG8yeDNoZFFDTXF5bzE5Q0cy?= =?utf-8?B?RFY5dWxZdkJaUzZHTXB6QTFMcnV5Z1JQakYxd3ZsYytJY1F6UEtMZFd3Ymo4?= =?utf-8?B?VFNmQ2xvRUtGaGxSN3NsMkxOSzl2U2hEWWNMN1lMQmJrOEdac2l6VytHY2hy?= =?utf-8?B?VEFMTWM2bUVjMjcrSUlOamo5MHVnMnArN0xqZXQ1OUVOajUza2JPVjkrSysy?= =?utf-8?B?QWt4SGowZ1BEQzJRd2U2UT09?= 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)(366016)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bStqbEEzTkNhc1lxZFd3eHd1MGxzTTk1VlppbVJUNVkwSU9US2o2VzFEQVZO?= =?utf-8?B?enJXQ2NnRkJXQzJKY3hUelhUUTBJMVIySlNnQUJSb1RxbkVYT204eTRTV09a?= =?utf-8?B?eHZqdkY5SWtpbWQ4MzNSc0MxajQ0THlMQkNadWdPcHUyVkljOU1STkhGVGdJ?= =?utf-8?B?TmtwQnJoa1dwR3lEM3p2cW9vZFZWSUsxdEphK1Z4d1RWc1BjQWdWYlY2cVRs?= =?utf-8?B?akdtM3l2QWFTaHA3Ymo0L3RPWWRtR0JsdnFKUGpSRnY1dHdrNzlJUmpwUy94?= =?utf-8?B?aWJNNVlpMFMxK2ZiVjdXUUduTEtZWit0V0lFaTQ4S09jb0Q4R0RIdzRUN3dJ?= =?utf-8?B?N3Q3Y25FNzI0NjZ1MXhFa3NnS1Y1elZ0N1JzV0JKTHRhQVlnbkZBU2F1cTRl?= =?utf-8?B?Z2tXQ2RpL3NYaXhKdnJSSmtTbExwUThzYVZpa0ZvTDVodkIxUE5ZM2RTbjhl?= =?utf-8?B?VnRQYmJGWWhOdzMvK1d2Rm5ibFdwKzhYYmtzLzI4bU9ES0t5clpBSVI3UU5R?= =?utf-8?B?MGRHRWlZaGdURlVqMVM2ZW9xVEY2VkNyWWpibytPMmdTZ3dZNUFxQ1o5K3pq?= =?utf-8?B?QU1iK3RmTVJTUy9pM0Z4YjZCUVNOdEI4NFNTdzRIY280aEoxUkNmVGZJMjMx?= =?utf-8?B?QlM1cEJGaTZDUU1nc0YxU1pZaE5lRDJNbWZVUytCWDlBaDJONC9xNDVPU3JX?= =?utf-8?B?WlZjUVdwYk8rcEUxckh6b3RHV3hubHh0Mkx1eFlGKzJLWXlydS83Kzg1V0g0?= =?utf-8?B?S0RZV1o3Nm4zWk5CTGhNbXZaeDBZQm9RZm44d0MxZVJ0MWJqNkNjcDNXeUlU?= =?utf-8?B?blI0cGxibllQWXdtU1M1MGkrdmNpa0ZpUktBUHl2eG85dW1NeFF1T25NQXFr?= =?utf-8?B?ZEdlUkJkWm00dklhWjFoRmVXNnRHYVdSa2ptOWJUM2R2d04yWVAvczl6ZVZD?= =?utf-8?B?TE9sOVBTb0pWVWdJNTFEZitNMG1iU3VyenNFOU9nMGFhcjBkKzVkVjRpeWJH?= =?utf-8?B?SGV1T21CZ1M1RnNWK3U1YVJKdVBxMXhkcm0vNE51Wm5FTGptNjJpV2NvZGx1?= =?utf-8?B?a3Nac0pEbi8xczRjMFZjNU9UYkJrYm5FSHlFSEd6QkVZaE8vb1hWTUg2T0lw?= =?utf-8?B?QkpSRit0QjcyR1pzQi9uVzU2L29JUVBqYUtGWGcwZFhhQi9IN3NPdUFiM0RG?= =?utf-8?B?b1gwSmhkZGM4UEtma1NoNG9RaDl2eTNGYndLTmZTMFUxU0c4Mmo3MVdmZkg1?= =?utf-8?B?Z0QzcDlhcUI5dFNKWDc2VW9vL2l3K0RyUmE0T1ZiY2xtdGVzRkh6NWorSVdK?= =?utf-8?B?VUcvMHIrd1hGM2xnWG9NN0hFQVJrTkR2NkIvS1JkeFRrTHNPdGVhbnk0TFg0?= =?utf-8?B?cEtXMmNuSmhGdndlMkttU3d4ajJPU00ydDdCY2ZuY2ZlRGpkbUUzT1dhcytB?= =?utf-8?B?aTV1NG4vMmcwWmNSZW5qQzhIVmx4ZVBUKzBpVTgxRUNPeE1qMEFFV0JRRGRR?= =?utf-8?B?WkxBZ2M0SzVTcWF2M2NaUDN1WWsyaFhSb1A1Qmx5cWsrOUdPaHBuOXpBYUJx?= =?utf-8?B?S25yQUlqTDFqaUFhcm11dVY2WEN6M2RFMHc3Ri94YmlRN3l1WllKQmZsVEFi?= =?utf-8?B?NTl1V3BkZEVBUWY1aDFndnZnVi9HdEp5eWFUb2tXdUNCZ2QrcUdxZ2xOd2Iy?= =?utf-8?B?NUJIZ0VlYkNwWDRwVk5wRk1POWVIYURSRFM2TXhMSGswTC9vczh0NHZORXpa?= =?utf-8?B?WmIvOFRPSExndXFndm1nY09saVhDTVdPTzgreWJRZWtwazlCV2hrdmdYZjhV?= =?utf-8?B?S0JtcEJibnhtcVlrcGlnWExoNVRZaWVlSUsyRjdFbmFmME5mNGUzdmZVSWlu?= =?utf-8?B?UVd0am50VUhhTDF6ZEtER1NnNDdLVDA4cmE5ZGZuRmY3NkRCd09JQnpiVTNr?= =?utf-8?B?T0ZlOGI5Zkh0Ris1b3pjWmIybi9CWnU0RVVIY2I1bmZaT3lxUzNMc3dzT2k0?= =?utf-8?B?UGtEQm1icGRUNk4xRlJBQkpKZ0xCamdkMWU1KytscFNsaklQYXVMcTF3d000?= =?utf-8?B?UkZaSktTOEpIZjJ1dHdTNTlEU1VUeWhUelhreWJqb3Y2ektLNVQ5UWhYaEpo?= =?utf-8?B?SlNZTUl2VW13KzBXQmdkdUlLdDRBd1Q3eUlzcXlLRm45SjRyWjFwRWN1dVlv?= =?utf-8?B?R2c9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 2varniYwYqx5OJiLRnofq6jxdYeThsp7Fr4kaEXfwAqS9HlakvQ7oTJbNmkrfXi+KZnCpHRJMvNDS3B/aVU3fSOaP6KrnB53v5bVGay4QC7SMVF6GqNFrZFE3R10Pbc9X7gExGf7Djh0DqIsrhDIJ+sQEgR5DntZ3FlLd+BpLzLPEYbnrv38Ay+YTM+WTln26rxvYyMutlzHHnWe2RDwQjW9L+6CJYh5dORomXZAiy8KBBZQLhINnB/UpsMyuQK8g74+Vcmfhl3kk56K4s3OJasq4yJTo8t2T0/oOcnlgP+aexWW1C3RB87XdT83Ws2IzXDDItL9k0KLe06HHw5cH9QZs0PC13OZhjUbYohuuoQ9Lw8ozh6wIV5Joh+oL5rh+fa56scacraVsOJNITVrqY1kNpXNmwND3qnrFziw6CyO1eVQrvrit3+BxGwdfH1UJzQ9VNPMtrHLLIPO2zOYynh+xqj8VOVd2sx0ycrEPBAqoX4FY+vN7BN3K3BABuuvLWPlGL7VKXGSUCYCJh58+A33qts0BViWdyhNN71wJE7fEPH5o0x3H+h2H0hcyoBZxXpYOnCMpqxPETzxTheu2Ct7PzbOf5YVE67obwsrV1M= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bccf664-6e0e-4420-61c0-08dd3bd062e4 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2025 17:07:15.5783 (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: fik3dSu/ZJtTT9GtFhy+hLwEpObDwZPlnO6W/ufX0hh/5L7mVnhRWjHYOgRJbIr1hM3Qu+3J2f7SVBxL0Oy9IQyD33Tl5vigxYa7F0I5ufM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6261 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-23_07,2025-01-23_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 phishscore=0 adultscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501230126 X-Proofpoint-ORIG-GUID: CY7gdNZ617n33Vi3NWuerVuDQ2hGTENp X-Proofpoint-GUID: CY7gdNZ617n33Vi3NWuerVuDQ2hGTENp X-Rspamd-Queue-Id: 62C7618001B X-Stat-Signature: kxzozjg39435gi86qowwxkpw38q1yx5e X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1737652051-113809 X-HE-Meta: U2FsdGVkX19+TM397Opjawt59hmUGs3OAsO7uKHP4icpGgwf96w4U3uWaMDr9uMihXw1GfMnD0KGB9ZBKQ5qaVt5ESAcMQEJnjexUjdpxdkuwIaL5fjsNn4SKZ9jzeGrx8PbNCHZMIEdlasFeSZ5mDI1k/liNegyeZyQtDkc6798x6eAQWFbygP/o1+7GPVDN/7Vy0UIGkD0pllwYr4kLWJ/Um+ewcJ7GNbPPre5/dEFFMvG/vD+ac5E2Mhy2cBQE8Zp1WoEygLbdKFwDbwdvR54m/AEWY+OexkKzqy2Qnfn2Wqi+eFnV4cEvo00re9EXvr0KNop46cgKsDxelk9LsisUxLkfJ/ooeuogEsUMj6Z4R8es4vdefCJp9k5AjZoiBGj81abSIfK0cqD5rAhdItvuZgcNUHt4frm46zqup7JogPvJVOcICztVlnzNDlWcW0xzdx4KhEkvVTY8m+aPzsZW4I44v50oNFQwry4MCNsMp9+fWeD5ASU/kvaSjOajfrTpf4app4f+NFnO/0zq6kd+oPCXFii2Zep8uBa65INyQtCxBtmpp/hmPlue2aBp5XG/sma9WT1E35ueHNTgh6CnF7CFiZr2/+2lCBhmG46vxS2tbWagqvSUh5umFI912nnD5S9WlIVjytE9uYc5ORh86QJHsTT5BbGwVo0dF/XaBvLFfbOH9UcV3vVeyOmcPbSD/KymPrmsLgi4+WCXNfvLDck1393DawhJ54XyuiTCaD1Cvwb1hLMp8QQN7wVTyOjHqI6njC43REoHpmZcUXan1sL4lXhceVHw/nrg6OCQ7wNnEuzzyU3NIkzN8JymW2plq/6V7FsnLzmAy+VTNAD83RVIHheJXO5MASrXXiiPGC5ETopGUCdHW0M4Psu+U4O6uSbTCtlladcL1V77smDtWRjbS7IFm1FvbJKTb9gcXFWpNsOerEyx+kGByxg6ufa9METhwdgJ/RGlMH z0WLWSBL cYKe6HVmgKtjIywfEjc9XDi74TLAXsmJNfCOZkb2rHYNJxlJisXkROMtpF9GeXEbVhxGlOEgMWHg1aAahg88yCRCSHPAQPv+SxboK8gJlcq4kMvqdNslEQ4GfMMojHAEcV041F3wgw7Pl1oYYNgztgZevi9zAtjuBfMM+4H6LZACZa5N5eK8Cl6qgkXnGG2ang3e5SWmj4VakwAr02YZ4kaX920wfInJ234OiMzPzSqluDey1lmYlFUyOwnu/HbY2r7r/kAMQT1xPiu4rKXacMzRyZxPh6yMa18ORCxc2s2RyYRTaGnb1dhNr9G6Jo/EgWjEg9TNycKCUxARvKO4HZbE28xmwlEjRhVUudUtUOib8a2O8Y9Eq8a/i5SkA6I/sh7/sF9eWXKWWkx9uCCqKjhCmlCI4lxMuhCHqiDXFcC6hoHb95byuJPI5RNAHXXc50S22htLvCwHcJlYAAvmrB3QdsWLc0GBBQt3OEtVGbA+ZIPj2K00+0ystLutEOWRt9RoJ07LmwZiyrxLi8I0d63WBz7bX0Fo31q3vVO3a3456Da2fjWRUUoNAWNHp7F066hPOiDfYL4OW1AGlvGJ5uctMDNyEx0hyDBxepMrPaxxkdVRGMUAllo/WCaPxgdcS0nu8OOC7M4eMttU= 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, Jan 23, 2025 at 04:48:10PM +0000, Lorenzo Stoakes wrote: > +cc vbabka Sorry my mail client messing up, forgot to actually cc... fixed :) > > I realise this is resurrecting an old thread, but helpful to cc- us mmap > maintainers as my mail at least is nightmare :P Thanks! > > On Thu, Jan 23, 2025 at 05:14:27PM +1300, Barry Song wrote: > > > All userfaultfd operations, except write-protect, opportunistically use > > > per-vma locks to lock vmas. On failure, attempt again inside mmap_lock > > > critical section. > > > > > > Write-protect operation requires mmap_lock as it iterates over multiple > > > vmas. > > > > Hi Lokesh, > > > > Apologies for reviving this old thread. We truly appreciate the excellent work > > you’ve done in transitioning many userfaultfd operations to per-VMA locks. > > Let me also say - thanks Lokesh! > > > > > However, we’ve noticed that userfaultfd still remains one of the largest users > > of mmap_lock for write operations, with the other—binder—having been recently > > addressed by Carlos Llamas's "binder: faster page installations" series: > > > > https://lore.kernel.org/lkml/20241203215452.2820071-1-cmllamas@google.com/ > > > > The HeapTaskDaemon(Java GC) might frequently perform userfaultfd_register() > > and userfaultfd_unregister() operations, both of which require the mmap_lock > > in write mode to either split or merge VMAs. Since HeapTaskDaemon is a > > lower-priority background task, there are cases where, after acquiring the > > mmap_lock, it gets preempted by other tasks. As a result, even high-priority > > threads waiting for the mmap_lock — whether in writer or reader mode—can > > end up experiencing significant delays（The delay can reach several hundred > > milliseconds in the worst case.） > > Thanks for reporting - this strikes me as an important report, but I'm not > sure about your proposed solution :) > > However I wonder if we can't look at more efficiently handling the locking > around uffd register/unregister? > > I think uffd suffers from a complexity problem, in that there are multiple > moving parts and complicated interactions especially for each of the > different kinds of events uffd can deal with. > > Also ordering matters a great deal within uffd. Ideally we'd not have uffd > effectively have open-coded hooks all over the mm code, but that ship > sailed long ago and so we need to really carefully assess how locking > changes impacts uffd behaviour. > > > > > We haven’t yet identified an ideal solution for this. However, the Java heap > > appears to behave like a "volatile" vma in its usage. A somewhat simplistic > > idea would be to designate a specific region of the user address space as > > "volatile" and restrict all "volatile" VMAs to this isolated region. > > > > We may have a MAP_VOLATILE flag to mmap. VMA regions with this flag will be > > mapped to the volatile space, while those without it will be mapped to the > > non-volatile space. > > This feels like a major thing to do just to suit specific uffd usages, a > feature that not everybody makes use of. > > The virtual address space is a somewhat sensitive subject (see the > relatively recent discussion on a proposed MAP_BELOW flag), and has a lot > of landmines you can step on. > > How would this range be determined? How would this interact with people > doing 'interesting' things with MAP_FIXED mappings? What if somebody > MAP_FIXED into a volatile region and gets this behaviour by mistake? > > How do the two locks interact with one another and vma locks? I mean we > already have a very complicated set of interactions between the mmap sem > and vma locks where the mmap sem is taken to lock the mmap (of course), but > now we'd have two? > > Also you have to write lock when you modify the VMA tree, would we have two > maple trees now? And what about the overhead? > > I feel like this is not the right route for this. > > > > > ┌────────────┐TASK_SIZE > > │ │ > > │ │ > > │ │mmap VOLATILE > > ┼────────────┤ > > │ │ > > │ │ > > │ │ > > │ │ > > │ │default mmap > > │ │ > > │ │ > > └────────────┘ > > > > VMAs in the volatile region are assigned their own volatile_mmap_lock, > > which is independent of the mmap_lock for the non-volatile region. > > Additionally, we ensure that no single VMA spans the boundary between > > the volatile and non-volatile regions. This separation prevents the > > frequent modifications of a small number of volatile VMAs from blocking > > other operations on a large number of non-volatile VMAs. > > I think really overall this will be solving one can of worms by introducing > another can of very large worms in space :P but perhaps I am missing > details here. > > > > > The implementation itself wouldn’t be overly complex, but the design > > might come across as somewhat hacky. > > > > Lastly, I have two questions: > > > > 1. Have you observed similar issues where userfaultfd continues to > > cause lock contention and priority inversion? > > > > 2. If so, do you have any ideas or suggestions on how to address this > > problem? > > Addressing and investigating this however is VERY IMPORTANT. Let's perhaps > investigate how we might find a uffd-specific means of addressing these > problems. > > > > > > > > > Signed-off-by: Lokesh Gidra > > > Reviewed-by: Liam R. Howlett > > > --- > > > fs/userfaultfd.c | 13 +- > > > include/linux/userfaultfd_k.h | 5 +- > > > mm/huge_memory.c | 5 +- > > > mm/userfaultfd.c | 380 ++++++++++++++++++++++++++-------- > > > 4 files changed, 299 insertions(+), 104 deletions(-) > > > > > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > > > index c00a021bcce4..60dcfafdc11a 100644 > > > --- a/fs/userfaultfd.c > > > +++ b/fs/userfaultfd.c > > > > Thanks > > Barry > > > > Cheers, Lorenzo