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 24880C7EE30 for ; Thu, 26 Jun 2025 21:08:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4AD36B0088; Thu, 26 Jun 2025 17:08:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D4B16B00B9; Thu, 26 Jun 2025 17:08:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 875CD6B00BA; Thu, 26 Jun 2025 17:08:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7147A6B0088 for ; Thu, 26 Jun 2025 17:08:55 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 160A058A8B for ; Thu, 26 Jun 2025 21:08:55 +0000 (UTC) X-FDA: 83598791430.08.1428037 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazon11020127.outbound.protection.outlook.com [52.101.61.127]) by imf23.hostedemail.com (Postfix) with ESMTP id 0755414000A for ; Thu, 26 Jun 2025 21:08:51 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=os.amperecomputing.com header.s=selector2 header.b=kJiWsmQu; dmarc=pass (policy=quarantine) header.from=amperecomputing.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf23.hostedemail.com: domain of yang@os.amperecomputing.com designates 52.101.61.127 as permitted sender) smtp.mailfrom=yang@os.amperecomputing.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1750972132; a=rsa-sha256; cv=pass; b=fPYVNQT4436i4cPOdq9oRr5VJ6/bQAW4JT20aXtj07qNLprJUtkUpc0lNxZsTQudNeCLHv 8FpN6W/qOFnrC07qNB9sFdsDrxlmb2myp1P7UaeJiFRyoWHnBZRt7lDKti500Lp/JF+4tF o1ic0Pu+wIN7k0g+F/9TrKy5tMoi6xo= ARC-Authentication-Results: i=2; imf23.hostedemail.com; dkim=pass header.d=os.amperecomputing.com header.s=selector2 header.b=kJiWsmQu; dmarc=pass (policy=quarantine) header.from=amperecomputing.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf23.hostedemail.com: domain of yang@os.amperecomputing.com designates 52.101.61.127 as permitted sender) smtp.mailfrom=yang@os.amperecomputing.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750972132; 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=X7/3TJ+z8DvU3DpJ/qCpodJeo8lUF0RQtRlOpJMIcQc=; b=7oTm4x93hW32HzIlbXKTtreWRgVXVU0aZS2BzWL3ShqtZvPmQgy0gt62+20GiYPIq4zaH0 FJPmyxZpcWYAr0a5U5A/dpX9TfWzeYJLzKkl+JZIYex7MCEe9h+YFFhFqHUKVu+QDJwOWW y/zYKBnk6HwGxu/4JfaD0EBTqGirhy4= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ryeFO9T6CWslcCDEXkOcPgCVWSRwYLAqy4WRScDuTGfdGnolNa2/SLfZXUcnN7okIIqCebScGOyITV0/UdOrwQWYrLQsVO1mNFk+FJr/1CASi8nsdp4FqWIV1Rxd99Te/+OFbAUiwIK0bBW5fL0ihQxmJoxkMUilEiwFZW7MQy0bGoZ1JLcg0PKmHjJCpfMWYUO+hX7cFuE/dJGOSBvkNCaU48XmGK9+y0LVsDggcZ6g/fDUZrhXTQOMnql2DF41Yay0nOkkvFZVHKuqQL+Cwf3i95T/s73mtAjqKGjbv9dnlhSbgVBsAo8dq65zosJ12MUoyPCF7gpIJaJF0l9SJw== 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=X7/3TJ+z8DvU3DpJ/qCpodJeo8lUF0RQtRlOpJMIcQc=; b=Md9UUzlEAOWCz6PFrLhdbBve0e1tlxkKIaTXNjpeB/t+AxcQbDsubLqHoZBngyCuiF//inXTzIYGlKUjRBpvqnMzgV890jZakjZsZ4dM38OXXcktnOIaG5KxtoOJKwlOMAf5T6MI/erGyeMSfNOckyDXlX6v1huk//6OaKyhoQ6cpY3paILvydlY+97yL3JMEHckNUwFC0ru4yrLLfhzOrqAU4yXFQJePeH4cBWygIjCPbPwad3XafMuKYmzyI2scm0JbEpU1Bf1QZm/HKi/aOzanB7VMuNRXWP/yx7UiJ//hAX5LWgF6jn4wr7ipgApTOs0UMa24U1w1SrvOlg+3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X7/3TJ+z8DvU3DpJ/qCpodJeo8lUF0RQtRlOpJMIcQc=; b=kJiWsmQugBrbQsexbEzKtNTVfkFzRDZytRFkaK3VXEPJy2/1QfjUghBwXJUVd0pjlrNh7VgFldcDTt0LYrutGFMSuiuq4jEqx3SmreaJe1x70TOblxCybwHl6/LwXJJDDrmbiy5iDXyux7o4esWBBhMVrHsmYXv+JICcWZrzJlg= Received: from CH0PR01MB6873.prod.exchangelabs.com (2603:10b6:610:112::22) by SJ2PR01MB8348.prod.exchangelabs.com (2603:10b6:a03:53b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Thu, 26 Jun 2025 21:08:46 +0000 Received: from CH0PR01MB6873.prod.exchangelabs.com ([fe80::3850:9112:f3bf:6460]) by CH0PR01MB6873.prod.exchangelabs.com ([fe80::3850:9112:f3bf:6460%4]) with mapi id 15.20.8857.026; Thu, 26 Jun 2025 21:08:45 +0000 Message-ID: <970c5885-8a06-438e-b626-e6640f9322f5@os.amperecomputing.com> Date: Thu, 26 Jun 2025 14:08:40 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] arm64: pageattr: Use pagewalk API to change memory permissions To: Ryan Roberts , Mike Rapoport , Dev Jain Cc: akpm@linux-foundation.org, david@redhat.com, catalin.marinas@arm.com, will@kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, steven.price@arm.com, gshan@redhat.com, linux-arm-kernel@lists.infradead.org, anshuman.khandual@arm.com References: <20250613134352.65994-1-dev.jain@arm.com> <20250613134352.65994-2-dev.jain@arm.com> <956f6ebe-606f-4575-a0a5-7841c95b5371@arm.com> Content-Language: en-US From: Yang Shi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SA1PR04CA0014.namprd04.prod.outlook.com (2603:10b6:806:2ce::20) To CH0PR01MB6873.prod.exchangelabs.com (2603:10b6:610:112::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH0PR01MB6873:EE_|SJ2PR01MB8348:EE_ X-MS-Office365-Filtering-Correlation-Id: fe73e060-92ee-4671-3108-08ddb4f5a33d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SGkxR2dGZHIva1pNU0cyZk1RUTdmY0xXczh2NzAwbkZnRldNTytSVjVGV2xP?= =?utf-8?B?VmkwUHdWOFJ0K0VPN3p2OHovdGttUmdzTUx4NGdOU0NmcktuT29nM3pyVHBa?= =?utf-8?B?UktqMitCYVpXeXpqR0d2bTFKbCtrNUhaT294SEM0VzdaRHNGd1lzUVpaK2tD?= =?utf-8?B?dUl1ZURrMGFuZTd2dERlS0t3MjlaSTlQbUIyZFdSZUx3TmpweUlWd0loYkhO?= =?utf-8?B?QlRWMGR6Q2dicnBRbytoelAvNXVEZ0FtaDhBMVNpcS9SY1NoR0RHTUZCUk81?= =?utf-8?B?WEJFVHhwV3dSbStqUmRXQ2hVS01BOCs0MVBMSkUzWmRPZW5Jd25vVVJ0Qmpu?= =?utf-8?B?dFo0akNQckE3Y1VWeWtMY0VwaCtTUUYrOUtDRjVwSHpGSW5lWnRsMFoyeVRR?= =?utf-8?B?c0pzUUZLaWxTb0draS9nZy9JMEZZY1FUcjc0RVFHVFNrbG85aGZuVC9XaWJU?= =?utf-8?B?RmxYUTM2Q29RVFZ2aDBEcWxiN09xaWIydUJlRDdra1NveUxHdDF4LzQwam9L?= =?utf-8?B?Z1hadm9NM1FIWXV2Y0I3OVFEYTB1cGUwbTZScDZhRldjOVJvOTdKSHp0dktr?= =?utf-8?B?QXZ6QWVuYnYvWElBSXFQOGZobWtjY3p1VmhyY25ReGwrTDlKRlU0OGtLNWZY?= =?utf-8?B?ZEZaZ3I0akRlL3R0L1dYdE9rV1BhNDRDY3h4SDhUWnh6VmZZcUJIdkJaQlNW?= =?utf-8?B?NVdHMkNsYUhGVW5PMkhlNlRVeGVXS1R3OGRXZUVTa1A0MXNDNUFzM290d0hW?= =?utf-8?B?d2J3OHVKMG1aZU5iZEk2RVFqcGVUaVFMb3kxQVZjQms2bEc0UWZzR3VsQjlN?= =?utf-8?B?Y1RKY09GRGRpMEhDRlVqWWY5QVl4SFRQYm51VDZPTFFldDZHTHRQUDhiQ29w?= =?utf-8?B?cEM0TkpHNzB1UDY2bG5WWGdDUFdiWkVPVlNtQXdPL0V0VUgyWUg2d0RzcnQ4?= =?utf-8?B?d0s4QjRsSDFsdFUweUMrYloyV3dNWE03ZGtsaFh3bElRYThvc2pwZmFpckFM?= =?utf-8?B?MmxLMjRzTEJSYXpxTUJVTWVQOFRtbEh3RTJwTHBnL2M1YzlxSGVaaVlDSWNl?= =?utf-8?B?b0dZQ3ZyWUZLYjdUVjRJak1XY2RHNExFUi9GTlg4U2dQMGd3N2E2TFBtOGxh?= =?utf-8?B?ZkpUNEF5NVA0RUFoaVdJLzc3cEZnbyswai92MW5DTU1lTVNBZmJaNGQ0NlN4?= =?utf-8?B?UmVQdUxoYkpKSXJjd2svc1VRQmM4aEV1S3dxMU1XZ2tpVklPbVhPai9xMk5E?= =?utf-8?B?dDV4U3JXZHVZcHNrelhqSXZlVGFDbnd4dkZJM3RrdVY0eWJ5QXpHaEZaMGxN?= =?utf-8?B?WHpFMlhCbElLVDl2aFJwdkNYV25rS2plTlBwLytsSU1XL3J2N0lsaWRCcGkr?= =?utf-8?B?M3JVaTJmMi9QMEloc0tHZGs4cVk2Z0NjaFZOckJkWTdwQTdNTU9DSUFmaWZh?= =?utf-8?B?V2hmRkRzWDlNMEkweDRkOUhlMDFsamM1cjdjLzVyWWJaWERlYmx5OHVEMnRQ?= =?utf-8?B?c0oyK29XQmo4djVnMzllOVpVU1ZNeU1QVXFvYWpKeUtycnc1aEVPR3c3ellq?= =?utf-8?B?MFA3NDN6WWg2THNQbDVWU0NhY05WbDlXSVVxTUJLSUxWMkdVL1BYQVY2RW42?= =?utf-8?B?SEFVQ09SZEZ2bFBCYmpKNlUyS1c0ZmFhNHJWYkZIMG5SYWtPVVVENncxTXpF?= =?utf-8?B?cXVFQUxoS0lINlExN045eDRuK2piY21qM1lKTU5rRmtIdS8xTFJNR1FLdzYw?= =?utf-8?B?ajB1YUozNk14Y0pqcWNrRHVCYmYvczBFMWk3K2ttNlFnL1A4clpqeHc1NVdx?= =?utf-8?B?M2t6VFQvVG9sL2o1dTdBR041REFKR016MGl4NUpqdkZGaHpucWgrejJTSEw3?= =?utf-8?B?RFpnaElXVndQZHI1QTBNZnNwdmpYNjlCQXR3QjFERTlndDZmUUtxRWRTd0lu?= =?utf-8?Q?DH7oCSXHlWs=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH0PR01MB6873.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d2E3TkFlc1lvcXpqUGVqLytzUkVXY0RYcmtXZWhwU3I3K2Zkc0ZnMWE1bDQ3?= =?utf-8?B?aDFXZG1GeHl4aFZ6NWZteW51eW5lQ0g5UGduL1BxWFVJaEJKYmZDaUF0N1dr?= =?utf-8?B?bHNHZjhGNHdZK2JqbXM5QktVR0pkZFRwNzVBeUc4cFVZOTd6bkNEZnRtaW9m?= =?utf-8?B?N2lVWHdUR1UzYjFnNjVSNG5FcHQvOFQ0WGc0Y3RGYWJ1emM5NHB0N2dGN29V?= =?utf-8?B?ajlWSjRIY2NDQmVjLzNuSVVlNVZ1QVNFTHV4TTRxTVh4dFNrcGtEeXFFOXJE?= =?utf-8?B?M3FFaWlTeks0ZHBkdTRXQVcyVW9DS1E0US9ZUnNWVk81VmJPbS9QWGg5RnZi?= =?utf-8?B?NjhWcVhSTmx5QnlxMmlwNHRvTGVmT0lEL1FrN3NuRCt3eUVPQlduTXNEWjgv?= =?utf-8?B?TWxEUU9scm1XR0lQTGRuTTNJM0xTdmJOL2xMTE9EdnVyK2ZNWWxKNWVES0Vs?= =?utf-8?B?S2I4c3BDRSszL1EwUXk1aDBIQXVkQUswSzh0RGtLdzlKcE1RQ2F1c1lINGxh?= =?utf-8?B?aytlak9ZUzVQQVFxSEpnYkc5QTE1UlVmYWNTWkVUUTJhTEJkRVBMd1FIVUIv?= =?utf-8?B?UW90K2xqdUw4cmRVanBIckVDTEI4UWYwNFdsdkc2MUZqemlUemdlMFdDblM0?= =?utf-8?B?U0g1bm1GVHcvL2hJU2JRTG5JbGNxVWZ2MDNEWHRtZHo0NHhmcTRiaGdraG9S?= =?utf-8?B?clVaMnY4dkcxWUtLVW84YSs3RTR4YWU2TXJHOWRjb015NENHRnNTMk9taUlz?= =?utf-8?B?T1c3T1MwcEVUY0Z6bmUxb3hlL0c4dFZYZ01DcjlpWDhlSERjTWVTOGwyZ2xC?= =?utf-8?B?bVMvdGxOWDVsa1U2RmNCaXlYMFlxYnIzYnhkaERjWUE2Y2xZZ2dWQVh6S1hy?= =?utf-8?B?V3F5NW9rT3RscGR4RjBKQ2JpU21DM0NrK1B2MWUwdW1ZMlFOWFhJejZNYk5Y?= =?utf-8?B?YllRSDZkMXhKcXIzdGJMQWg3NmdnMHRsK01MR0dUT2h4bGZHN0RLQjlscUZL?= =?utf-8?B?MXFLbW5DRWszeEdNWmhBYzNvOWQ2dWgwcHFWb0Q2WHFiOGFOYWZuTTBaUHFa?= =?utf-8?B?ak9OM1JNNFNicCtlcDdlbE5xTm5FUGFZK0VvaEFXWjVLUmdDa1ExbjFNczhs?= =?utf-8?B?TzhnMlFEdE1IV0pUSWRWNlFLUUg0a0dHa1FNTjczQU0zN3hrNnMwRTg1NGtB?= =?utf-8?B?bjJSTlVRMEJwSy9XeDBRdjZHeHIwZGNiVjVlb0tRRHBnb0pucTJuTlhIdU5a?= =?utf-8?B?M0lXbFZMRVY5VWlCbithYlZZNmxaWC8wT0dJWnMvQmRmc1ZLYUtMcFp3MkRu?= =?utf-8?B?R2dZWlpZY2poU2R1VUR4TStiRGdPN0Z5WlVaM0d4WVpTaWUyMmxsSTU3NXd5?= =?utf-8?B?OFZCRjNsMUwrZWFWa1d3cFg2d2VMbjRTbUs5N2NlK2doUnVYcXVETVVteloz?= =?utf-8?B?cmhIdzBVaWdQSDdhK0k0dUQvSENacE5UZ2FmVCt5bXAxNlRVbzFhbkE5WEpS?= =?utf-8?B?d0lLdHhRQUdtMTZpL2U3WkkzOGRTMEViQzZWVVlKS1NCY3ZEK01HUjZZb0Fu?= =?utf-8?B?cHBHQTg5VWJHc1MzbitzUmpLemNlRjg4Y2hVRytOR0tlbWRJTnJNRFdndUNK?= =?utf-8?B?dEZCWXQ3MDFubm5ERjNpTHFSNEsvaGxwajNTcHBCRnpjZkphcll2Z3hiYUV3?= =?utf-8?B?aVI4bzVGeU5CV0FFOU1ZdzhpTTRpV25tY2I2RzVXWVlNK1Uvc21HVlJhbmlj?= =?utf-8?B?MTVxUmVsRXRwSWFLSDgxUUI1dmQ0Mk9SME4ydldKRjl4eTFPUktQdjlUdGl3?= =?utf-8?B?M2g4ek9XanZUZkw0aGxORkhJSVhyNm9ZdHNaaEtmd1hjazZUVWtQdmRDUko0?= =?utf-8?B?ZWszYlBCMGY3VlZpdk90U2JldC9tcE9UdkJ5cGhLY05MMkx4aEorVzFsSUlp?= =?utf-8?B?UkZ1d0pRTjRweXBlOVJKZk02T0phV21mMmtENEtDTkJhSUE0ZjZ5ZFFwMEk2?= =?utf-8?B?cUwyemk1K0MzVVdpSmRSVW1Tb3FqOExTTUFDd1hmVHp1TG9EajNwcTdrcFBo?= =?utf-8?B?cFgzK2duU0d0N1VLL29VNERhd09ISmw1WENmNDZDNHlvVE1JVkdEWElJQ3ha?= =?utf-8?B?Q3JtR3RzMkRDLzZkUE5vOTUyeU5hWGF6YUNCZDdXbmxiTXYvWElTWVdGUEE2?= =?utf-8?Q?H723+FKYZDwnUclmRWkuHgg=3D?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe73e060-92ee-4671-3108-08ddb4f5a33d X-MS-Exchange-CrossTenant-AuthSource: CH0PR01MB6873.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2025 21:08:45.7247 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sxCAyg17iL12z63JABQSKqX+Hy5IpPHHNASkRHZwqTdDmfmCjjnkz2gFEsONjIwE/hShv3NBAOKLUHofQpjVvKaGOM/fyjBtWCwLM8B9Z6I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR01MB8348 X-Rspam-User: X-Rspamd-Queue-Id: 0755414000A X-Rspamd-Server: rspam10 X-Stat-Signature: hmw7gko88pagzkhemskqhxtjtjxbmhfd X-HE-Tag: 1750972131-104706 X-HE-Meta: U2FsdGVkX18C7fpS5hOBCTee+lDTmMiejpEAh/gOTLn9FlEL/OGL9D8bI+sOJgk0sa6WelHvuS8AUZslAoR+mt6BX4WExgvKtfQHogYAY7spEL4WOrdqB9QTiLcJQMSCOLvulTrkyjBmA5Wy7En5FW3Ddkkr6VjQ0v/f+RbaCcXJqWT6ByGfUlINRE+b14YAOjSKnBKyHtkE9Gsq5f/Q6PaVe+gOK6DnbTbgYAYqERbJ+ZqhwpEOrcqTYijhze2S4p7dIlEAonarhoIZPrr7N2p+tZ4LCt40H7D2x8qHhO/5KfjFPpgKIofY61P7Jupc37SsmUoC6Q8W1K78kv7Jh94v4Tghyrb1eT5LLyRGWX6DMKfjy73lPChS9iShBGL6bL4ytmKJtDy5LMXC6rbYXDAchgmmKhyAn7bLnCWFl2wxbnH/XQeHMbRgck1kjuRSyanUEARFTPuBqosLOB8mOl0Ec+pTd0zCFVVgtAxteTszez8hrOYhR8Votz0Y4jKHmIKtcMAazE/r3VyKLoouyMXUJeRe5mekQHX5wrsiil1n3Xt5q902qFruIX3x6g8EqtSXV/EqscX3Kszte+DzuL/RVpefwNvqW70noLCTQX7f35JFZCOC733JsFXeiXuefwxWdevYYu9qp0n0DEgAQLV0ZGPI/3TnMONrhFWsgoT9CYKVPNazFozxkPo347l+UfH/3HBu1F2C4t9Cnaq70vUWZdVDmFr8d+YnoofMpelxk6Lcp6xLdL71QswiOWEJgy6ltfFFRJRUnz09vdZXcssx4QeWqVwSQqwXWvfPXPCi59cE7k5QoMgzYPr4v8SGrj2Oe/6gRFqxs/nkyrlU9DAKNCa9baZLjcWJDKvsXCuJ8033+H9MoQttTs/VMCF15cgFDMK5AzOBnQdKYHlyH37yAM/ylsDF5i4XUybePmsbGe+DsaWBQ1fpmiExE56welHKIZ6nGbf6Uv6xO5u D5GkNNEs zjCn/9Ust5lMFiOa+5ogm5855r/lacY3KinXIALi15POD3qBrDUt05fmpzZSrWPgZg4ymYjmF1Of2kPXjFT9psS28G+katW8A7YUwfi/nNrRvgjPpxjHNhIOwI6bUax0i9bO/Q4l43TtkBh9nO1NjnNYx+F/JdeITIniiK21SVX4mn9PBr/7pQh/HAsKZEXX1xxxRp5u/9y3ka5QIuqKZUIFCuDniryokXku0PBBQamiXDGZxwr0M6noxsbXowpbN6KNypLuM3ox0Rz2zQ0uKpatxS9fXejSo5AvgXm8CUS+g//JiB3kFuT8sHRfpTw1SDdpDUGxgWj5Wxno/Yp3AffXqAAhDhGcnkKSYoxF+gPQwvM+rNEvakZt3qnwFAdzGL/WMgLGCW1tFve1Zw61qip0kIcfW6YmTub+CXV9DC8owQsUqMvmg3OeAE/0eXEebMfsdjMK9OlUxe3GF60aeOSNQEmkNcAGsgx5yfR8guFXeR0qJmYzmI8ySOcSv+1vN4k8uFnHExyT4KgVzQOv1kix0khqRfuCvOfBzlGmkLyi5hZW9tVt+0qAErcCNiRorHPmg5dyrMfe5BJ8TEtBsAeiNn1o4CCARUHrBZaWqxQ+MK+M= 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 6/26/25 1:47 AM, Ryan Roberts wrote: > On 25/06/2025 21:40, Yang Shi wrote: >> >> On 6/25/25 4:04 AM, Ryan Roberts wrote: >>> On 15/06/2025 08:32, Mike Rapoport wrote: >>>> On Fri, Jun 13, 2025 at 07:13:51PM +0530, Dev Jain wrote: >>>>> -/* >>>>> - * This function assumes that the range is mapped with PAGE_SIZE pages. >>>>> - */ >>>>> -static int __change_memory_common(unsigned long start, unsigned long size, >>>>> +static int ___change_memory_common(unsigned long start, unsigned long size, >>>>>                   pgprot_t set_mask, pgprot_t clear_mask) >>>>>   { >>>>>       struct page_change_data data; >>>>> @@ -61,9 +140,28 @@ static int __change_memory_common(unsigned long start, >>>>> unsigned long size, >>>>>       data.set_mask = set_mask; >>>>>       data.clear_mask = clear_mask; >>>>>   -    ret = apply_to_page_range(&init_mm, start, size, change_page_range, >>>>> -                    &data); >>>>> +    arch_enter_lazy_mmu_mode(); >>>>> + >>>>> +    /* >>>>> +     * The caller must ensure that the range we are operating on does not >>>>> +     * partially overlap a block mapping. Any such case should either not >>>>> +     * exist, or must be eliminated by splitting the mapping - which for >>>>> +     * kernel mappings can be done only on BBML2 systems. >>>>> +     * >>>>> +     */ >>>>> +    ret = walk_kernel_page_table_range_lockless(start, start + size, >>>>> +                            &pageattr_ops, NULL, &data); >>>> x86 has a cpa_lock for set_memory/set_direct_map to ensure that there's on >>>> concurrency in kernel page table updates. I think arm64 has to have such >>>> lock as well. >>> We don't have a lock today, using apply_to_page_range(); we are expecting that >>> the caller has exclusive ownership of the portion of virtual memory - i.e. the >>> vmalloc region or linear map. So I don't think this patch changes that >>> requirement? >>> >>> Where it does get a bit more hairy is when we introduce the support for >>> splitting. In that case, 2 non-overlapping areas of virtual memory may share a >>> large leaf mapping that needs to be split. But I've been discussing that with >>> Yang Shi at [1] and I think we can handle that locklessly too. >> If the split is serialized by a lock, changing permission can be lockless. But >> if split is lockless, changing permission may be a little bit tricky, >> particularly for CONT mappings. The implementation in my split patch assumes the >> whole range has cont bit cleared if the first PTE in the range has cont bit >> cleared because the lock guarantees two concurrent splits are serialized. >> >> But lockless split may trigger the below race: >> >> CPU A is splitting the page table, CPU B is changing the permission for one PTE >> entry in the same table. Clearing cont bit is RMW, changing permission is RMW >> too, but neither of them is atomic. >> >>                CPU A                                      CPU B >> read the PTE read the PTE >> clear the cont bit for the PTE >>                                    change the PTE permission from RW to RO >>                                    store the new PTE >> >> store the new PTE <- it will overwrite the PTE value stored by CPU B and result >> in misprogrammed cont PTEs > Ahh yes, good point! I missed that. When I was thinking about this, I had > assumed that *both* CPUs racing to split would (non-atomically) RMW to remove > the cont bit on the whole block. That is safe as long as nothing else in the PTE > changes. But of course you're right that the first one to complete that may then > go on to modify the permissions in their portion of the now-split VA space. So > there is definitely a problem. > >> >> We should need do one the of the follows to avoid the race off the top of my head: >> 1. Serialize the split with a lock > I guess this is certainly the simplest as per your original proposal. Yeah > >> 2. Make page table RMW atomic in both split and permission change > I don't think we would need atomic RMW for the permission change - we would only > need it for removing the cont bit? My reasoning is that by the time a thread is > doing the permission change it must have already finished splitting the cont > block. The permission change will only be for PTEs that we know we have > exclusive access too. The other CPU may still be "splitting" the cont block, but > since we already won, it will just be reading the PTEs and noticing that cont is > already clear? I guess split_contpte()/split_contpmd() becomes a loop doing > READ_ONCE() to test if the bit is set, followed by atomic bit clear if it was > set (avoid the atomic where we can)? > >> 3. Check whether PTE is cont or not for every PTEs in the range instead of the >> first PTE, before clearing cont bit if they are > Ahh perhaps this is what I'm actually describing above? Yes > >> 4. Retry if cont bit is not cleared in permission change, but we need >> distinguish this from changing permission for the whole CONT PTE range because >> we keep cont bit for this case > I'd prefer to keep the splitting decoupled from the permission change if we can. I agree. > > > Personally, I'd prefer to take the lockless approach. I think it has the least > chance of contention issues. But if you prefer to use a lock, then I'm ok with > that as a starting point. I'd prefer to use a new separate lock though (like x86 > does) rather than risking extra contention with the init_mm PTL. A separate lock is fine to me. I think it will make our life easier to use a lock. We can always optimize it if the lock contention turns out to be a problem. Thanks, Yang > > Thanks, > Ryan > > >> Thanks, >> Yang >> >>> Perhaps I'm misunderstanding something? >>> >>> [1] https://lore.kernel.org/all/f036acea-1bd1-48a7-8600-75ddd504b8db@arm.com/ >>> >>> Thanks, >>> Ryan >>> >>>>> +    arch_leave_lazy_mmu_mode(); >>>>> + >>>>> +    return ret; >>>>> +}