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 DDA1BE77188 for ; Tue, 14 Jan 2025 18:21:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69D4028001C; Tue, 14 Jan 2025 13:21:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6271328000F; Tue, 14 Jan 2025 13:21:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 451F628001C; Tue, 14 Jan 2025 13:21:57 -0500 (EST) 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 1D17A28000F for ; Tue, 14 Jan 2025 13:21:57 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B1D3D160BC0 for ; Tue, 14 Jan 2025 18:21:56 +0000 (UTC) X-FDA: 83006876232.11.883A4DA Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf26.hostedemail.com (Postfix) with ESMTP id 623B0140009 for ; Tue, 14 Jan 2025 18:21:53 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=RDnY2flC; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=vd7OHpvX; dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf26.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736878913; a=rsa-sha256; cv=pass; b=oQrJOflFRT30qnVT9oL/l0Elc1IZgfwfqNQJsnVsPtTPTc5rsM+FxemZFngMDJq9A7Knae RYx2L7l0+rIOJujqeMMxUFzDjmQdOKLNxsAixZiCW7ikCvSKnIB6N2UjK3oD1YBKjrFx4l VQnbPTCYT7cngyy35V1ecKxqhNExXCE= ARC-Authentication-Results: i=2; imf26.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=RDnY2flC; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=vd7OHpvX; dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf26.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736878913; 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=MepVWdm4yZ5iOHZFNaUksyBI7YsdMmojPZfQSYGJIvQ=; b=tSjYMFaIs3yq4jFHCbkVlYKDlvrqn6cYA297Y/XarnEMFQMM8GlR9D+fpwZKP8R/ITIXjI mljzYxuGFmXciZIA8jkbICUuWL9+aNOGuTOmSMdFQ8nb21lUGxeadbHAQXTDfzzapG9ELG 6YDz9RXHIrKO2IgbGgHEp7+m7VviEvY= Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50EIHd59007850; Tue, 14 Jan 2025 18:21:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=corp-2023-11-20; bh=MepVWdm4yZ5iOHZFNa UksyBI7YsdMmojPZfQSYGJIvQ=; b=RDnY2flCyl3VBxoVhsQWAFIRN0ATF5L4/1 pbFuaL4JgV+A0vGErmbPf0Uylu14nx/CXUb7QI7dVEud81h14sigRd2gAM5qUKkg dkxW77LTcMRG7cbyj5OicRct8YIGrfrP1Z0eRJMjDqMMHyw3Lv23/mnAq2xkuuWl boF6ITMOonPgTB+UwFoFbvGpyhLmhWRbzhUoLQZBXO/+FB6s1tpTe/hpkjpj6Fvu QYy2BvxrGxLw9qGigRMT51nVHqssXPzAuKAE4MWy6d/Dtk/ADt27mX3LHHS5PKQn oh5nmnD1nuD2sLh+2Ph++hVNW6WC7s0dqYHWsuuu49lpduqM4b3w== Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 443gh8x5uw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Jan 2025 18:21:35 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 50EIAOVB032222; Tue, 14 Jan 2025 18:21:28 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2040.outbound.protection.outlook.com [104.47.73.40]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 443f38fvg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Jan 2025 18:21:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hjOn+UbeYLYhKjkzkoFwQY5UU1W/TrreaeOLFDrYNaEolN2Rt8POZ6zCOpPofHa0HTC5CouxjRyHjePNZHD1/y9Q056WgCHkqAw/+/6BK8eYjag+NOZZQ7MVtyh38BCC+g5n76DUci1dvTabjmECr6dNqjLTqdgCuapBs3KAf4B4kvy9gs3+8EjHKqDZeR8CgNcB3+X6nAW6W0yL6zFWRhJrU7AIqLuyRO67dFFxMG/LOiZF8IXjorGyWqKAWrRxKRiOH9uG0Nvo3fpK2IpfG60hYj1VFvtfRAzbr4mpjniqtWq4PXdHA1NbazK80PC37PAb7F7SzP4+KiEa5UiEXg== 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=MepVWdm4yZ5iOHZFNaUksyBI7YsdMmojPZfQSYGJIvQ=; b=ojZLGFwtNnmBmDwWbFZZNPs+3265/EpHGo85kl5G4hqhxGV8h78jTSBDboA2YttFbwHyrDxIEt290boxzYuTTQx6aM7TDbYZ06WQWNnAyfWK0R+CLPFw4uezo4NZBZ3BrAoHU5esq36Jr3+/L1F4mXf8W6OTCKWi4u1S3s41fkgSO88jjnal+3Iaav/vpqbADzW/C9JoWzwRAKST7kGfPDhat60W3GCGnRPjlWkWPn85cbFdDWtLtL8CjlojuPpLnokiAWuUSkCTc8Ws/KyMbz5+NHlpGot9m++mLJgG1QSLahzYMrOdY3XM7Ph8hXCKFTGTgcUJZBQWyNRpPy1DxQ== 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=MepVWdm4yZ5iOHZFNaUksyBI7YsdMmojPZfQSYGJIvQ=; b=vd7OHpvX7+DP/8DljjSXE/W+dBdoxdvdF7rBWksX+98KYbEkXy1LJQz2Oymtkow/ibPhQ7BA0+tBcTGHqvCcsFdqJgT6bsCz1QZfCCoz9CdPdjOa9YrA+J9kyc91zI4KD9wbkrxjlKeQrL2TZYAS0tzwSV22z/YJzmay71+Mj9s= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by DM4PR10MB5991.namprd10.prod.outlook.com (2603:10b6:8:b0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Tue, 14 Jan 2025 18:21:25 +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.8335.017; Tue, 14 Jan 2025 18:21:25 +0000 Date: Tue, 14 Jan 2025 18:21:22 +0000 From: Lorenzo Stoakes To: Yang Shi Cc: arnd@arndb.de, gregkh@linuxfoundation.org, Liam.Howlett@oracle.com, vbabka@suse.cz, jannh@google.com, willy@infradead.org, liushixin2@huawei.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] /dev/zero: make private mapping full anonymous mapping Message-ID: <9ab0fd08-7f3e-40d7-b2bf-8af40b464f18@lucifer.local> References: <20250113223033.4054534-1-yang@os.amperecomputing.com> <2dda50aa-e4a1-4664-b8fa-56ba975db329@lucifer.local> <65691afc-615a-4716-8a2e-1f43bc65111c@os.amperecomputing.com> <3fdcd6a5-27fe-411b-923c-b7410e4cbda9@lucifer.local> <10f5cb31-e9fa-4574-b36d-0e685fec5cda@lucifer.local> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10f5cb31-e9fa-4574-b36d-0e685fec5cda@lucifer.local> X-ClientProxiedBy: LO4P123CA0498.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::17) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|DM4PR10MB5991:EE_ X-MS-Office365-Filtering-Correlation-Id: 8fcbe815-7bf3-4d48-518f-08dd34c84199 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?l6ZN1tlF1u5FGdJkUCx135T9mntzv5acur3FRbirQ6secPtHpXFcFRk78a8K?= =?us-ascii?Q?4uUSUYANJpgvnNr3F5kWyi3QBiKEKmDMJdEDcHhU8q0GHxfY2gPpKYkxyJNO?= =?us-ascii?Q?CNc85KVdgBozOUQrkmlmaF7bDGRGgViADpVTOsFNcyTKGthJ+flg/upPAR0c?= =?us-ascii?Q?a2vlBK6GJRg6NGMz3aHiewxnX9rWYzSy8ANalGCsjlS+YiUpRYmdHjFBHCsY?= =?us-ascii?Q?fgc31cRFVqzL8g6vtgk12U7PyPmI1kwYjBT7m4asaxOmyfgUL5tn2SOdnHMn?= =?us-ascii?Q?LJZbitoceoCfEGc3y3AouwKklDosFV3+oErM2aGWhPph3LioAROWzhQdD1Cb?= =?us-ascii?Q?sI7Cuh7P8edOyoZlqvXKf1HUPfF7Y7eVgvKOYkpVFUBVT8BcN6YF93dIjPpS?= =?us-ascii?Q?sgsYMF5FZawVP7OB81YbwTJ0JpLuiDNoRR7SuM9mZMPwcFseIydGHh1mi/7x?= =?us-ascii?Q?7X0OEsJEUh0ZkN/slfDxVWUHOubAXfv4wrKX7PJFbdBrxiOoew40nic8q5+g?= =?us-ascii?Q?bqqydte9fJEaeVq/Pxm5HraFcfi4PNNaH/rNI45pYI1oUWLeRtAFqXgUH+++?= =?us-ascii?Q?hSkEq+irt/K+2792nhJZg2iL3t8jgk26N2dOWE1ETZkXkTRsh+9ionvSUCWx?= =?us-ascii?Q?MWdfT7g4Shi1JBv8pi0Nf+xOjjevtNwEBoEJYvMWjL2KxPfRtKl/CPkVb5IF?= =?us-ascii?Q?QIbwrM8pToZyRMstJ1HQbPRLbotxdmhzJHKQoL4lzmVJ020NB19N3SJsDhhj?= =?us-ascii?Q?OZ6RvQu9ndQahXPym8AQ5kgw9omHLSWaAvAvoecPn5AL9aazBS/8A2z37yms?= =?us-ascii?Q?eiLqZAxy10iscNIuAPuO1YPcYTlGNanJMxrpx8BJRIWNX0SjrtGUWkmGg3Bw?= =?us-ascii?Q?QS4b0+yxaOkIce0yi8LDtnHpAr3pRxJqhoU40C3vOhTF+++PsgoDF29M8beS?= =?us-ascii?Q?Af1yP+nsPjzrhYFf4DK7SvD6wI555f+C5u5KmYZuQSa2lGrGjEfZoBxQekXW?= =?us-ascii?Q?vEDxA0CLIqt6HDz0UuBvQ9CZCI3wN0dB991pp8IjvhA/9R3OA0L4Xf4WTRrN?= =?us-ascii?Q?n7eHL2EFiPhDpZ77pXDv7WxVf7vPvfm4kFs/gkfdwk8YRd+TrPQUJ/vllA2w?= =?us-ascii?Q?m8IV7Bl0dYikDNkmaRF58fLgo9xeymKHnppApYRTvyRd6awCRnf4vyfhzOZF?= =?us-ascii?Q?UwkMkuf5D8j36mCwxl+8X0WJAe/YAht4phvBKGnqX00ZUnFXQh/dvYeMh1yC?= =?us-ascii?Q?n930vqPYcvj3fNl4P4fvGcjSV0X7C6qwk4hJ9tzIWnr6QFGm0SpR/qL2znZW?= =?us-ascii?Q?ciLxztYm+q3MDIJLnfbyMN9Tb5U5nlcp8nOKdHCfKHKkRTdAa6+y5QvvL2ai?= =?us-ascii?Q?dAnOV1SyjJdQnwiMpWWHfyANWL/4?= 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)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/A/NH4wV2oiK7ybCw7PAFf6Wc7hZ9L2QXjtYQm8gLMac2i0frX2y2RTYKRWv?= =?us-ascii?Q?2ZZGy24T66Y4bfvb7rpB+xLpPeOc91tInqvHz5XbmncsM+Xupql52x/E1ROy?= =?us-ascii?Q?mT05cMetVHEVH3maFYStI848xgiO7KqGe4+0UkWM9nd4NpumfAZz3vubdHrv?= =?us-ascii?Q?bWtQU3pmjsDZYwjFcvC6nmpnXv/DBiklZp0mtkAxBLUhBgOpjFANA46NhauX?= =?us-ascii?Q?ErOAtwC0BmSJzTbk5iy8mn3jugPq5dhwRMjyJdaKa5KBWgCsfxc1K84cqOWL?= =?us-ascii?Q?lm6/xhZ/4mVJYmaGJnGrPOli3k+MWlUTJ6z/1Y9y/SExSDRWQt+oyTKNtYm4?= =?us-ascii?Q?vbMerW4zQyaOf7SgzmWDo+GIBgRTJfoqvFpN9/iccSEUmTRhKdPm1lYS129D?= =?us-ascii?Q?BmU/lbS1VHc/I/fd4dedhmq8+GADV3j0fPG7942CmA5NvnXDGjHEksm9gNFf?= =?us-ascii?Q?q1jE5I16D4eFkSihOmS52pXhzoa5EOsFdFZS1CV8XWXBOczz9xRVBN/eYeL5?= =?us-ascii?Q?N6n+7WwPERVKn/pv72VkStK8VGJSnOiHFqxAH4zQ/HJv+iB8tIkvmFIX0Uyz?= =?us-ascii?Q?DuF2jSSgFFuKiGtqnHBXjYT72pFHSaRkT1cKOK50185HK9eXda201XUzSKRV?= =?us-ascii?Q?YxEKQgyF2WsJtOLSHdvgzyFQwLWButWoStYyvFOUiDsyVx+0d8aOlVCXhyCf?= =?us-ascii?Q?ZjtEv3SHkYW6/+9plqEMTSYMlMIaOdLDtNBiZGOGDi+VYzulkJKMzhZCw+Uj?= =?us-ascii?Q?6nY6HgVzFzTT4J1YJSKUbWDfsH6j+PI1nd63ML+XrOe6jYryrdQfJ0MApEfs?= =?us-ascii?Q?Q/5W9uio5w8IeNuYos9C8RNYeYl+0U5GAncoBZkyHyVN2HoeVNnQ+fs93mq/?= =?us-ascii?Q?5/qC57W2vhAagDtjA6y/E9UIgLmQNcgSc22K31rsCh3aBT08Fjuqx25+urlI?= =?us-ascii?Q?xwev6CKKGHgOxxeb67+vNi7LhseU7SixsDnknzIVAeCMGUG7B8Oy6rB1lMG0?= =?us-ascii?Q?txFCyEHjwD1iHybF9rLfK/4dcPaJ0bjvvx6OsAiXDGxYa9z7Y+4M8d+Q7Pi8?= =?us-ascii?Q?ReLWO1BJNvcDUrv6kOQZdkhdCR2SzLVZFn86QS0zcue1vq38gGElQkhTNxAR?= =?us-ascii?Q?AOxDLvPj4Ypjp5vseN8ZrJU76RAfi6A3mX5a3sNXO3E/rL1Rxdzo0gxNxdYz?= =?us-ascii?Q?aQaBD2A+UNJ1D9sqKok+tkJMXl+3SYh33D31GM7TboddGw7PDP7CnyqGCb9X?= =?us-ascii?Q?EZtTvEdDAruwqPHKworP+ScVCmJa7dYx1/X+grZDXwgcqpSv5ybkjRz4SEAR?= =?us-ascii?Q?jnnsWfneXUTMquKXF/7TFSDLn39zS2NyfoIDJKumGWl1bpKR5HhSt1wj8JLb?= =?us-ascii?Q?Ub7okAzS9V7T0IYUzZW8+GZCdFzuk7yhuFVIxoBEa6hg0XbrwVfTAF2u9eQi?= =?us-ascii?Q?Rec+gN1QBKdecWdxbANjuaD7L3/U5o/w+MOjMQvohHYblttUg5fBOc0iNuzH?= =?us-ascii?Q?iZge2QaSlpn+vZfPnkTxGkypGKCYnDK0Mq2FnrNqwSKyileqWEFJ+wtfHWnI?= =?us-ascii?Q?Uhbu/7JOz/D8qJ1/5+0y09iSAMnQmDv5RqkST7J/DmD5NCeMheK5QKtJF9rl?= =?us-ascii?Q?/g=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: abQLG+T+tumH4iUI4dOn2uKPqu+3kFtFA0L3yDLTapzkgmEp8vADb+Xr1AOr7/jfgGFVyAxvfwE9cS3+YIC7xhGSmaNdUqFUhB7p6YmnkNR0SNa92ReYfk9o/y2DMX/c/jbREEd8pCSAn56kocOYYZNGtZyMsGEDcUAH0FuPOhEzfUCbyfKDSMyuz4S62CqVjLmK6pw0XxWdTNEALAaGzQW0SsrgDS6H0hU+AQnhZ8CQ1DxmWbMQUdDo/7oYYd0JugRVxlvjJdQ3hsrrNJBbIkhey7R1tSlZmgrpgQmbQk0EPJG+RP/E13F3TH2HNFlErsbnuRjTU4RI0GMdJCXYJMu9nur2WDFUoMyHeaq1td0lrQeKF/yPRxESWJUoa/v4Lpn5kFRtZFWxPcTWENBN8wlTKHb5Q84dwSeBB7HEgFkvRbHvzfwMUbKEwef/aSXAV6YiB+4iN9Nzl2FV8ZK705ND6LYIAZtkXZrDHwlWXfWNOzhHeNIfXifCjb3M1Q6HTh2SB2OUo/ajmtNG512DDt8xBu3K43mZyYqqNER0UkXT/Sov6fqTFu3kt7+ruXGWFaPtrBO5Vvv2z6bxrOpGFdIOjSJmyeqiEyaHJ2jgbVU= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8fcbe815-7bf3-4d48-518f-08dd34c84199 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2025 18:21:25.7548 (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: S7NtyAFKnbHDPet7Dh0wVSCRXzg31pM62k3l9i2vlNWmEFvIuQf/e78x82tXr2L2B9n2lBXM6opuT2pKuX1ZP/FdeNtZL6Myt7fNholObuI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB5991 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-14_06,2025-01-13_02,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 suspectscore=0 bulkscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501140139 X-Proofpoint-GUID: oDsvejV8y7dxURLdu-DwRfKWp1cEKeXL X-Proofpoint-ORIG-GUID: oDsvejV8y7dxURLdu-DwRfKWp1cEKeXL X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 623B0140009 X-Stat-Signature: 8q3wyu6fuaa1zgjuxr3iczrfg9yanoxj X-Rspam-User: X-HE-Tag: 1736878913-584013 X-HE-Meta: U2FsdGVkX19T0OyO7svNCy978xN2EQ4JeHjecUZQGFRdWnY7JCC5HvfRegojuIq/AART6relD5fGVyMe68HSr55v9qkOZjxe+4KUii3mYxDJj5Ga26u08ksOsORwZANN4rj1nL2xJCGcZgxCXYZQ5efJhlfk3mAf+drE4CdrZnFko52SRSQfceNu0gewV04UIlYBDADDsJiloUCH17zNRsnC7i1sknwLsHsCV0VV+DfIBlTnYiRreD9fhkGGUM/ky2zHcvxLpabHboy3sew3I8A+GBQ4ePCvhA6nwsE5L7w+dodmeOd8v5tuXlvwlvPyvmy+GGGwXqyCKvXC+5B+jUYk3FRoQT1asX3cgdL3NRNLTURgs7qYMp8mmZRJNIHQAhy0YSE8J6grOcmM3IXXP6QCbm73XIc94D3DRnyAerhCYfvZv0+1P0TyTVcFXM3hP/Vcrruf4BCiZMYVPmeDpOWP/6QFPysLv443IN0V6P1HPGXmwvuAvfJX0yByPcDkL9INjnDHu3yZTI9qFmX4fatAy8enh5napSKS7pnXKea5eHsgDriVSqdzgtw57IpwhB9yMffC9EQrssWsLeGVi+0TSgqHYyt/jc71wnA/bQ95EtN1RZfxkwSAfoMP9zE1b+FkhPXfMpdFtLRAGP00P5eFKZVTPg6qP132F8DofufBaBSn9cHPxijkcLkj296gYQE8eggZxBhLRfA/jdR/LlMb2nVvg6jlJAQ0Tk8kcmc1FmsY/7oT5v+EeR6HUsGqH2Jf76/dXVDfN/z0VW2qI22kWZaQp173sen2dAr24Uinv3bPdU8pYTA2JiEQKVpHgIe/4lUodzlfsgq+usP9RetPMa6fpX9SMzylyehHS7JhnD734OlCYJBGm4cVLExLIydDL3w+yMosX3CjmVNyQo4nLCuPRvtnFe14LsQdikrxRDnOmXTJRe8OcP2jbr5duM25U1jx7Ok6l+F6Kly zMnk/YR8 RS34mXS5U8LklRoNi6Y56wOmehem96xAbNSmcyBntXtVMR5+xTBz5kPNDwanxsIi3RjCTOhs/Y2UCBiQ0m3SX1N9JA+/lPO9iqu+0jtehJUJjROQSFFWJIa3LgXbETHdrMGXKMlUXoBfZSdIHkPfA6pSVK5hiOqdfLHxyNDAm3J4dREwjdSzPLecF4oMurbliD7+ii9I9m5G5JXqBAi89TvU0I9rnaZDFlstiTzKSDOIle28dFcWmtvp1BUCuRVKuOst2qYDKg4InBrXegIksubll6YhhAr4PfnXXhbVUvlC4jQXHLsCla0gBcC68a+E4nIQsXpZsAtz8B+gnwZ5MtKGtqUu8jUkKJpzCzcy6+nEeKVHiAmr50yp1kr4yh9MnED5LEggt6p3COvp9y5TyfVB+LzdIJCO5B76VFEQ+52d9BO0j4phly1ZrrMvYfodByoKqKU9+vpNh5VjUUWsJ2L0iSErvIFfjjHaBVj/jslovPqg/0aoDtl2iVyGmgt8e3l9YLgWZbp6yfRDAosQqUESHzmjBWH9NJGx03CcVfGxSNTPq/hM1tOR+XienGpnQEZK2kDKrJUY/q0cyubXLo7lGcaGIPra5rTIdQ7i46xb4XTDjXhfjKXfOHjVt92oPgUtygNKUz8BNtug= 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 14, 2025 at 06:19:32PM +0000, Lorenzo Stoakes wrote: > On Tue, Jan 14, 2025 at 06:14:57PM +0000, Lorenzo Stoakes wrote: > > This is getting into realms of discussion so to risk sounding rude - to be > > clear - NACK. > > > > The user-visible change to /proc/$pid/[s]maps kills this patch dead. This > > is regardless of any other discussed issue. > > > > But more importantly, I hadn't realise mmap_zero() was on the .mmap() > > callback (sorry my mistake) - you're simply not permitted to change > > vm_pgoff and vm_file fields here, the mapping logic doesn't expect it, and > > it's broken. > > I see shmem_zero_page() does change vma->vm_page, this is broken... ugh. I > will audit this code (and have a look through _all_ mmap() callbacks I > guess). Duly added to TODO. But definitely can't have _another_ case of > doing this. * vma->vm_file... it is late here :) > > > > > To me the alternative would be to have a custom fault handler that hands > > back the zero page, but I"m not sure that's workable, you'd have to install > > a special mapping etc. and huge pages are weird and... > > > > I do appreciate you raising this especially as I was blissfully unaware, > > but I don't see how this patch can possibly work, sorry :( > > > > On Tue, Jan 14, 2025 at 08:53:01AM -0800, Yang Shi wrote: > > > > > > > > > > > > On 1/14/25 4:05 AM, Lorenzo Stoakes wrote: > > > > + Willy for the fs/weirdness elements of this. > > > > > > > > On Mon, Jan 13, 2025 at 02:30:33PM -0800, Yang Shi wrote: > > > > > When creating private mapping for /dev/zero, the driver makes it an > > > > > anonymous mapping by calling set_vma_anonymous(). But it just sets > > > > > vm_ops to NULL, vm_file is still valid and vm_pgoff is also file offset. > > > > Hm yikes. > > > > > > > > > This is a special case and the VMA doesn't look like either anonymous VMA > > > > > or file VMA. It confused other kernel subsystem, for example, khugepaged [1]. > > > > > > > > > > It seems pointless to keep such special case. Making private /dev/zero > > > > > mapping a full anonymous mapping doesn't change the semantic of > > > > > /dev/zero either. > > > > My concern is that ostensibly there _is_ a file right? Are we certain that by > > > > not setting this we are not breaking something somewhere else? > > > > > > > > Are we not creating a sort of other type of 'non-such-beast' here? > > > > > > But the file is /dev/zero. I don't see this could break the semantic of > > > /dev/zero. The shared mapping of /dev/zero is not affected by this change, > > > kernel already treated private mapping of /dev/zero as anonymous mapping, > > > but with some weird settings in VMA. When reading the mapping, it returns 0 > > > with zero page, when writing the mapping, a new anonymous folio is > > > allocated. > > > > You're creating a new concept of an anon but not anon but also now with > > anon vm_pgoff and missing vm_file even though it does reference a file > > and... yeah. > > > > This is not usual :) > > > > > > > > > > > > > I mean already setting it anon and setting vm_file non-NULL is really strange. > > > > > > > > > The user visible effect is the mapping entry shown in /proc//smaps > > > > > and /proc//maps. > > > > > > > > > > Before the change: > > > > > ffffb7190000-ffffb7590000 rw-p 00001000 00:06 8 /dev/zero > > > > > > > > > > After the change: > > > > > ffffb6130000-ffffb6530000 rw-p 00000000 00:00 0 > > > > > > > > > Yeah this seems like it might break somebody to be honest, it's really > > > > really really strange to map a file then for it not to be mapped. > > > > > > Yes, it is possible if someone really care whether the anonymous-like > > > mapping is mapped by /dev/zero or just created by malloc(). But I don't know > > > who really do... > > > > > > > > > > > But it's possibly EVEN WEIRDER to map a file and for it to seem mapped as a > > > > file but for it to be marked anonymous. > > > > > > > > God what a mess. > > > > > > > > > [1]: https://lore.kernel.org/linux-mm/20250111034511.2223353-1-liushixin2@huawei.com/ > > > > I kind of hate that we have to mitigate like this for a case that should > > > > never ever happen so I'm inclined towards your solution but a lot more > > > > inclined towards us totally rethinking this. > > > > > > > > Do we _have_ to make this anonymous?? Why can't we just reference the zero > > > > page as if it were in the page cache (Willy - feel free to correct naive > > > > misapprehension here). > > > > > > TBH, I don't see why page cache has to be involved. When reading, 0 is > > > returned by zero page. When writing a CoW is triggered if page cache is > > > involved, but the content of the page cache should be just 0, so we copy 0 > > > to the new folio then write to it. It doesn't make too much sense. I think > > > this is why private /dev/zero mapping is treated as anonymous mapping in the > > > first place. > > > > I'm obviously not suggesting allocating a bunch of extra folios, I was > > thinking there would be some means of handing back the actual zero > > page. But I am not sure this is workable. > > > > > > > > > > > > > > Signed-off-by: Yang Shi > > > > > --- > > > > > drivers/char/mem.c | 4 ++++ > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c > > > > > index 169eed162a7f..dae113f7fc1b 100644 > > > > > --- a/drivers/char/mem.c > > > > > +++ b/drivers/char/mem.c > > > > > @@ -527,6 +527,10 @@ static int mmap_zero(struct file *file, struct vm_area_struct *vma) > > > > > if (vma->vm_flags & VM_SHARED) > > > > > return shmem_zero_setup(vma); > > > > > vma_set_anonymous(vma); > > > > > + fput(vma->vm_file); > > > > > + vma->vm_file = NULL; > > > > > + vma->vm_pgoff = vma->vm_start >> PAGE_SHIFT; > > > > This is just not permitted. We maintain mmap state which contains the file > > and pgoff state which gets threaded through the mapping operation, and > > simply do not expect you to change these fields. > > > > In future we will assert on this or preferably, restrict users to only > > changing VMA flags, the private field and vm_ops. > > > > > > Hmm, this might have been mremap()'d _potentially_ though? And then now > > > > this will be wrong? But then we'd have no way of tracking it correctly... > > > > > > I'm not quite familiar with the subtle details and corner cases of > > > meremap(). But mmap_zero() should be called by mmap(), so the VMA has not > > > been visible to user yet at this point IIUC. How come mremap() could move > > > it? > > > > Ah OK, in that case fine on that front. > > > > But you are not permitted to touch this field (we need to enforce this...) > > > > > > > > > > > > > I've not checked the function but do we mark this as a special mapping of > > > > some kind? > > > > > > > > > + > > > > > return 0; > > > > > } > > > > > > > > > > -- > > > > > 2.47.0 > > > > > > > >