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 14CACE77188 for ; Tue, 14 Jan 2025 21:24:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 864EC280004; Tue, 14 Jan 2025 16:24:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C8F2280003; Tue, 14 Jan 2025 16:24:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A44E280004; Tue, 14 Jan 2025 16:24:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 30F78280003 for ; Tue, 14 Jan 2025 16:24:38 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B46B044551 for ; Tue, 14 Jan 2025 21:24:37 +0000 (UTC) X-FDA: 83007336594.08.837BFBC Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azon11020105.outbound.protection.outlook.com [52.101.46.105]) by imf17.hostedemail.com (Postfix) with ESMTP id 9995940013 for ; Tue, 14 Jan 2025 21:24:34 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=os.amperecomputing.com header.s=selector2 header.b=batJRZKe; spf=pass (imf17.hostedemail.com: domain of yang@os.amperecomputing.com designates 52.101.46.105 as permitted sender) smtp.mailfrom=yang@os.amperecomputing.com; dmarc=pass (policy=quarantine) header.from=amperecomputing.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736889874; a=rsa-sha256; cv=pass; b=S1ZL9CHNEYjHNy91R2y46pQ9jkMEXXUkgW0jMvHcbof3D2KwczY14u40nWk79mteGd4AQU bKekUmYwKkZR9yxTknzDFrcG0FU15C3Myi0WH9kkt95Y1iGG6YlnamxZ/q6U2PekFZ8/WG nlGhv9n79xQ6rjHl4Na8ik6mPAL9nqs= ARC-Authentication-Results: i=2; imf17.hostedemail.com; dkim=pass header.d=os.amperecomputing.com header.s=selector2 header.b=batJRZKe; spf=pass (imf17.hostedemail.com: domain of yang@os.amperecomputing.com designates 52.101.46.105 as permitted sender) smtp.mailfrom=yang@os.amperecomputing.com; dmarc=pass (policy=quarantine) header.from=amperecomputing.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=1736889874; 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=F+F6Fl0WUbLB17CPMe9scXMpd6m1/KrJ0yExVHUp1G4=; b=Qg204ghep8cu2dKygCu4bjWPXj1DgJPKLLJHxU2MsxCG2Y1RnUYA9uaEp87VdrHp+XgShM jfa1+WEp85s1r8zpt1vA0rQpvwYppzt9JlCKsK0LFd1cHZksGyIxwC3LmDN6uLp/ID5sbH JCoLNaY2FkbXM95GYZpRWiIvI7w3xC8= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zOKf+2VihP274dY/LrXQJHUqlxFXcoyf6wlPtdQKlcP0DLmV3UMDELWFqc9tJhUB7t9DzNX96Ke8KJ32TUWY9BUiur/Ucs5rXFnDcyR4ShR5sqDPlK9ZI/wtT4h1AWXwOP1cKpMSj484kugZMVTFkYXaFXglqBdfqL1jpdWuM8XaxhVLwcnszprC0WShmD+2zjsbn7iyYk2XW0IeS8POryFJSKtoOZKS+3842rxDzSZSfGFMnF+bJdVzGgbE9uqCUFZqNZvagPK4OVjiVcL/Bn9DA+3BHH9AZHs+ypYh7MetYgXsNDXhqHFfU2YODf4g1VQS0e0R2rxKWbaoAgrnwA== 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=F+F6Fl0WUbLB17CPMe9scXMpd6m1/KrJ0yExVHUp1G4=; b=fpKqpMw/qRgkUctEpn6hs219753XeShtcOLGiLBun9GF2D2nhw2LJ1omiq9/rabM4ut0RmFU8KX38qw6/K2ZpKu0wcIy2mI+uIkL7xh3x0NZH+oHeJPz69NHVZS5SfpsoSibFXkTfrWU+LbBbkhGiqmw6P50tA+J3/xK+78iBUe+5o1i752yg5p/K6nTTcVg57CcsM5TsXFu+U5WyEyTKw772QL1wKreWyXmrkmzAGkzvJmP+KkKMvemr6NY0yJtVLzM8QkhqW0FXx4T3jARYuM+zgiLi842RjmxOUVKr7HLfmfUzcKGkrNyhCaY8z52PFgissokMMZAu8EY107KAw== 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=F+F6Fl0WUbLB17CPMe9scXMpd6m1/KrJ0yExVHUp1G4=; b=batJRZKe8RHgDYW+5ABWgnXQeAJXp4zy91gVQg0GhIvogfl6cepDFUCSHuu+39eqMChDIhwPvfK4bqx3Lm706rABDSuGKoFrmVIAjJ3vzImzuYvZ3VUXm+AAi4ZfHtc6aRfkcuJEI6B41KefdeDT0kM9ECO56vmdeYvdwWk7nmk= Received: from CH0PR01MB6873.prod.exchangelabs.com (2603:10b6:610:112::22) by SA1PR01MB7312.prod.exchangelabs.com (2603:10b6:806:1f7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.11; Tue, 14 Jan 2025 21:24:29 +0000 Received: from CH0PR01MB6873.prod.exchangelabs.com ([fe80::3850:9112:f3bf:6460]) by CH0PR01MB6873.prod.exchangelabs.com ([fe80::3850:9112:f3bf:6460%6]) with mapi id 15.20.8356.010; Tue, 14 Jan 2025 21:24:29 +0000 Message-ID: <23f50178-59d1-462b-8463-48cc707d6b3f@os.amperecomputing.com> Date: Tue, 14 Jan 2025 13:24:25 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] /dev/zero: make private mapping full anonymous mapping To: Lorenzo Stoakes 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 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> <389c72c2-f102-4d32-886b-99d7c212a295@os.amperecomputing.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: SA0PR12CA0024.namprd12.prod.outlook.com (2603:10b6:806:6f::29) To CH0PR01MB6873.prod.exchangelabs.com (2603:10b6:610:112::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH0PR01MB6873:EE_|SA1PR01MB7312:EE_ X-MS-Office365-Filtering-Correlation-Id: e2272cce-f438-4540-dc59-08dd34e1d449 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?c1I1RWFlL1U3ak5UTE9oTWQ1Um1WS1ZZTlpBTFN5c2Zzc1N5Q1cveWJEaXkv?= =?utf-8?B?TWliRzkwTVhFQ2dwdGhjYWFxcVlXTGxmd29KOTk2QzVNVXc5SDZ5SnpzMkR3?= =?utf-8?B?bURTakVuZG9TZTNHRlFjQk12YjVFcEpqNUt5OGNsNnoxRWswU0FoS2RlM0VC?= =?utf-8?B?WjM5QTNWQmpjd3BENkpOSDhOeFdLRTM3TVhEdHRmTTd1OFRzSGhFRlVnbUVl?= =?utf-8?B?aUN5OTByZE5PdGlqbnVCMitIajNybFA4Z3BBS1dUamVJRzZ6SXlYbDBtUWVB?= =?utf-8?B?L21Ua0ptMGQvYlNYWXZJVVVGeUw3UFBRTGJGMW11QTdKaG15OE8yb1RteEU2?= =?utf-8?B?aXBFdlViQzE3dUFIY1JBelQ4cElQZFhkL01aeWRYKytDeEhSL0RiSzlrRE50?= =?utf-8?B?Nk5xTTdRNGJXampVbU1makpSZjJrL2UxS2hpMXF2L3ZJZVdDM09oZWcya2E3?= =?utf-8?B?SzNOd3ZqWng3L0V0SE14VGlQL1N1VmxRVFZKUlZYY0ZabEVRcE9pTTI3NXpn?= =?utf-8?B?aFVmS1I3VHVxUnBmTk4zNkVZenBCK0JBSysrU3N3N2phQzJBV2tJbWNIZWha?= =?utf-8?B?ZjVGUjZUallYRDVFcTFRMzRMbUFEZjdzYTUzK2hBblMxMUlmbmQ3VXdkcFFn?= =?utf-8?B?bUFhMElvRGNJaUFhYm43bXJtdDgwWWJhOHVqeVdhSitrQ2kxWC84R2FudFV1?= =?utf-8?B?MlFTbms0Z2daQk1zK2U1eFY1alJRLzR1d1c1SXJuQ1liaW1CbEp6dVQxeUZB?= =?utf-8?B?VzRZYTdHY3hibjZKNzV2TlU4ZmpqeHNEQno2dUZLZElpaWUxd1lxZTZ0WXFV?= =?utf-8?B?cVJWcUFsRWM4YnNwWU1TaXhDQStjR0p2emJ6ejh1dUI3M1d5YjFtYnB5VHQ4?= =?utf-8?B?dEVrdnpyR3ZjZTQ5ZWRRRGxrUnFJUzBOQU5lcU96L2JUOFFxbjIwNUxrTDdu?= =?utf-8?B?a1BPV1FjL2hKRUd0enZmZTN0T3JZS2ZmU3JEK0FqcVdSY2luWnNNSG9Semlo?= =?utf-8?B?WVJHbDYrUlg2K2VlYnJGTS9kZWdJUi8ydys5R1owdzJMYmpvMzlWaEtTUGZH?= =?utf-8?B?RTZ4QjBFR2NudFU1aklWY3FKaFM2RkI5UHdWVmhNcFp2R2x2MTlJNHIyQUts?= =?utf-8?B?RjB1VC92U3pQMFY4ek5wK3NHK2xHbzNvamVkSmN1T21Wc1NhM3RjQlhLS0dt?= =?utf-8?B?WFM5U1BVdGNWQUIzcVhUQm15Y3Q3OFk2dVpMNE0wT2JUVGlTa2ZYWXA4YWx1?= =?utf-8?B?WHB6TXYvWEsyZ3BucFJIdWdCTHdhMmwzcWVDRklGRWROZ0FIYnMvcXN4WHNu?= =?utf-8?B?VVA4TmtMQnlBV2hNcE9ES2o0d2pRVXVSVi9ZK1pqcTNPM25NYUxiUDdyN0ZT?= =?utf-8?B?R0FZRTQyRDJYbVNWTVVBRFFXeGdsOVZjZTNNaDF6ZDJUYmd2RXMwRkkvZXg2?= =?utf-8?B?cUgxcTYvWHZTelQwWmt6elJaWnluTTZPSXRBTDUxbmxmTG80c3hJRXAxNEdm?= =?utf-8?B?bzNLZnFYMUl4YXlMNW9aRU9LdE1qYVUzK21sVUNIaXJubk94Ui84dE1XS0M4?= =?utf-8?B?bFpEVGFISGd1UVQvYUNsazRjS2J3RmtBdmhtclRkUGU4WS9QaXNuVzkwR2Nw?= =?utf-8?B?M3dpMXd5bTNYQXBRb0R4c1BmMVZMUElvczU2M1RWYWVhM3FsdFl2eFA1TFJt?= =?utf-8?B?U3JxSjQ0Q0ZjVFBZbWpJc0RGTEdCVmdlR2cxb3ZpN1FxUUY1NWhOb29hR2E3?= =?utf-8?B?SUlyYnllT0lweHZLQi8rc1Q0aGtnbHNVRU9QWjZZS05HVSthQ2pxb2Ixd3Vr?= =?utf-8?B?cDVGNHF6ckwvSTlEN3FTeEVyQkpVRlBjWGdBbU1EWExFS1oxc29Ea0F5MFF4?= =?utf-8?Q?dXAbcjLcjvfFc?= 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)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eXJ3cnc5QlZDazFsTFM1bU41MVdXTTcwR01CY3dya3BoWU1ITW44OUNqZXFV?= =?utf-8?B?am9uTGxSOWNNbWhpc2xiTGc1dk5La1loZkdXODBJVjFQOGcrMithSlhzYmFz?= =?utf-8?B?b1U3cEJpRXZZdXE0dWdobWZjcjRjUUlvUGtVQ3g4MTZnSDlWS3B4TEVvaG5U?= =?utf-8?B?Y0VmeTN1czdhOGZRbCtiK2w3QWpwM21lNkloRG5aekdBSUQ2SUI3S2p2MnRG?= =?utf-8?B?OFRLZnJ5M3BJbStGUGlxbVRLOUc3TXI1TFZwT3NNSVp3S1U1TGFFeXFBMXd0?= =?utf-8?B?S1NLTisvTko3SzlyWVd6ZkRCM0FnNXhPckxSemZaRFliOFFoZzVNeEVNdlhx?= =?utf-8?B?M3lHT2p1S1RvWWxXZzZVazRFSTcwd3JTaSswdFRwdXhpK04yamRhQUo5L3ht?= =?utf-8?B?anFlaGtPUDJOQzdzRXNkT3RrYVhDRHdOTGhkcWNlOHRpRzNzSXo3RytSMkFv?= =?utf-8?B?dG9CUFB5QzBmNkZPWTVsS1QrTVBQcXJDRHdiWjVoMkNHRHQ0R1lLTGtiKzFs?= =?utf-8?B?N0J4RjIxeExBZFhjQjhGUHRsQUVERkFzZEZHTkwrSDA2RTM4d2Q4SGVYVGhz?= =?utf-8?B?RTZrT24za0tFR0FpRUJDb1FZRkRiS3FFK2JDQVZJazNKQ3MvUTJqcjhsRGdE?= =?utf-8?B?RTRzNzB3c3NtaklVK2JNQ002eWo0WGVXYmNuaGNEdS9XMlFvWWhycjFpSjdz?= =?utf-8?B?SExsa29FeHJ3ZHd4QXRLQittelFRNnNIR0RkWWFicmExWlhMalN2UFUxVlha?= =?utf-8?B?cVY0RHNKTVRmOG9oUFRwd3k2cHR6OFdYVVpoTnIrbUVDTlNXNytWbW5QQ0dW?= =?utf-8?B?R0FGejhBNXlGRkZTclNxcjZ5VG0vWEdSTWNDVk1DcGpUSFJISUROUFdXa0hs?= =?utf-8?B?MmxOOVdUVjJlSGxlYzZRWUY3RDdlclZiYjlRQ0ZsOEt2ODBsbHJiWnhQOThR?= =?utf-8?B?cW9jVU11VVhzbTlqVWV6YWQrVHFnZUpaLzhRRTJ6U3p6NUZOb1hPM1J3TjlK?= =?utf-8?B?S2VDZHUwamVpcHoxcG0wck80QUgrU1NIZXdiSW1RUHpzTC8vM2J1RmYxQUpX?= =?utf-8?B?eDVybG5CNkNjSXhJOVdlMkRQTEVnOFlRZTFCQ2I4UDlGcGhCM21qNXFEcExz?= =?utf-8?B?UXpOdFdXbml6dmswb2M2S3FiSjVhc2JHSiszOEZqVmVTYUtWckltaHExbTNO?= =?utf-8?B?UldGdWNncHMyM2o5TzNYQlNHbTFmNFpBZks4cHhBZCtocVVMSmx3OUt2dUtI?= =?utf-8?B?S0NhNzVYSmlRdHlwejZRMmo4RmdoTE9VL0QxRElGejVWK0V1Q2xBRFVsclRX?= =?utf-8?B?NGpvSUhxOXJOZExuejhqZ0lOUG9vdmtyVldadGxBRDJMWW1qT1U1aTQyNXl4?= =?utf-8?B?RVJRNWlpNHMrazhYdGtaU3lFVzBiekt2ZmwzeFpCcTgrVG1paFUwV041TlN2?= =?utf-8?B?MjVobGMrM1JRZnpQQUVXSkk0TkRmOWF4RFozTFpWbTNDbWtsTG5Ua1pVNTBm?= =?utf-8?B?TUpXTk1BbGxkbC81SXROQXMvYjFNSzhuQVRyTk5rVmFOZzVjUHZHTXpEVjQz?= =?utf-8?B?cUlyOURjSDR2bWFMdVJRSkxoREw0ZHVaeDRuUDduSmk3aGJUYUlVYWVpZkU1?= =?utf-8?B?Yi9rTGhyWmx3VGF0T0Q2RkxuMXVBZFZXUjQ1Z0NDU2JCSG9ENVViTWtyTkZn?= =?utf-8?B?RERzaTdEeVBiUW1rcS9XditVbjNhMnY0QisyWWIzOVJ6K0tUT1FtRHRlM1JW?= =?utf-8?B?K1BvZ0x6a2ltNjFoaW1MTy9vVmluTDhRVDRUQXB2ZFo2WU4rRWdrN080ckNn?= =?utf-8?B?UDBCNWN6bG5YSVhYbC9kWXQzUUwyYjlEUnBFZTQ1aGZlWDlYS1drL3R5Z1li?= =?utf-8?B?blgxdWlaZXlkSDRnRzlOZFZiYlZKdS9ROHFzdWtSZWNIR3Z6QkEvU2dhSU5r?= =?utf-8?B?N2JtYnoyamRaZGdxSmJvSGJ6WVNqOXBCbnFzZkI3bFpxZFhqSndoWlc1V2cx?= =?utf-8?B?N2RmNTdlYXhSV1M3MXhOeVZvd3plNklUcXU5a1NrNGVndlBIc215SklETUpr?= =?utf-8?B?SmtsQ0RWZXJPQ2l5MmtBV21pMlhRLzV1MEIycDhLK0oxZkN4MWNVazF2YjhO?= =?utf-8?B?a2YrSlVqeHF5VUVsV085WnM0OGNUa2VFV0grUEh1UWlNeHVLamtiMmhZR05l?= =?utf-8?Q?FmYLkL42MHD3gNd+CITcFxI=3D?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2272cce-f438-4540-dc59-08dd34e1d449 X-MS-Exchange-CrossTenant-AuthSource: CH0PR01MB6873.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2025 21:24:29.2100 (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: Ui8x3jM4jVKdrAL3TalpdA6cSnBetY0p7pCTdhCVX8UDifMjGmuFhfDuSnRjqUH9h/v/IfqJCQmr43hL/bpQDtquLtc/GQhpNNGo0rvqw1Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR01MB7312 X-Rspamd-Queue-Id: 9995940013 X-Stat-Signature: ym5uuqgasuuhgr1r3bi1zqowhodyrwzc X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736889874-905043 X-HE-Meta: U2FsdGVkX180m+K61dTzIEpbpr89thGvUgeNg6qb8puqIngPnuUdmfm1+q9HEBE08NYe4/q+l+J6p+I/DhJSRaPhuMD3jIxywF6W/Dw0Wlo8N0GSMu26n5ICvrbpWAnohHoycZgdog4MRAobOt92WHzSa2+YSDkjoV1piYuZeAJNkKcFv5Jb6bQAPVFfJ28rjCcYhMId5UWbOehA8DSyDiPEHQW0iJnwOK8KNWVnFGzETf7axqyDbPctvdtDdB1PdKSnzotKw33LZ0ccGFDGUtF5q8W5b0HFJOXRMi0yAurOx5uBtDfaqNYi0QZwMziufovGIZHQQeY85FcXLwuL1JFnXp9+MrAiiTGFS7UIiOkBMjCaqaD5/4xENTqYBAmTcH62NrJE8DfUezrsfSDNh9TNnorQzrlHXWEqQ9HZnR2CoL7tSVBLEVEG+ZQWTrK7IfbopQacVNKCgKy1DDHhKs2YmDKp+IjGz/ngeLL+pjI5dx2CeL0GJwcg3wLE6e6DnNtRmJGnHEMWz6SgdKHOhDqDd5Gh/DpFVfIkeNgr9nhMgIqxUYkHcX/SjKN5Fvhzt/dqXtCpUFC4Y8AQ88cs64u8ithpF11l1C5ePB+lUogOWAb3XW+SV0Hj4UM86aQj+A+gVsA+V9H2+OM3uTSo8k/k4fAI6/aknszZ7vorJGOq9a0FNCzhvSpKoB2wg3O1udH7VwkCJj1JXk8T6DUtVq5EvVSu9zGbVmBnmrqfhLGG3NRv/E0SeNoAP7I6WkGmk+ppULs1nMKd6B0Ufdmx7J9yDoZ54kXJItLU3tsTCllvKLOEpffYw4qrEj0b1rJl8q8cs8v79HF8fKBMWMEBlbwHoGIS9UKuPUoKuEbNpENn8njMJ5Xu3yXKsiVXVvK/Jn0O4w+g5JHRWuIF6HisxlTCAsJ/625uEEWZeUQvp6QAK2l4xd3equcS+t7H2ErDMOXqIokmZfOIGq6eoI5 SSSMmsiX kshvsyaDXPn0+67UL0qxd6hZ9YifXO61w0fQvm2UxnqdpCk4vrrrvOtK2WMUxpAK/4LqzIiqBAoMG5hPjVovvdHeorF6ezyRkENGw3hn1xISIBJCA+mYC411uU/n8vzeOMTKGxgqgy3ioklZpEMPZBBx63zGRRr94TZhGUPqAT0R2Cpxk/IWcv+ov98N+86bzziMKapJPN1gfNtObndzDWO2cq5sADOaalcynuq4VSpKJchBAq/3lrDuGBI7s7YSh6Dm5sc1rvCkFPGcHH9XajoA9wuNZB1rwq0em/DzWWYXjsUQ5uzVgzLn7FqD4h5F2p3pUNRETQ05Mugt/Nu/ERhALUjZ0xLmznuh5rm26zNEYW2ZfUNtuF3FXZWQgdbqcH8i3ZRAUS9Jg3SLAn2B5J58sUbxlt7sXCfulGdDsbB1v9FIT1SWvRRfrhsMqnYgodLq2oIQD+syqPkr9lDIEfh8Wk1HRlpHROu7b1UmescTdzdWmS6xrAgS21e+biOI9ywbKhQh9HCj7K4fEdO8wZDqpfMoETQgfnWmP0YnGinXoNlym8hrBL6aQjqfXEjCrG0ynEB3XVO///yI= 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 1/14/25 11:13 AM, Lorenzo Stoakes wrote: > On Tue, Jan 14, 2025 at 11:03:48AM -0800, Yang Shi wrote: >> >> >> On 1/14/25 10:14 AM, 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. >> I admit this is a concern, but I don't think this is really that bad to kill >> this patch. May this change result in userspace regression? Maybe, likely >> happens to some debugging and monitoring scripts, typically we don't worry >> them that much. Of course, I can't completely guarantee no regression for >> real life applications, it should just be unlikely IMHO. > Yeah, I don't think we can accept this unfortunately. > > This patch is SUPER important though even if rejected, because you've made > me realise we really need to audit all of these mmap handlers... so it's > all super appreciated regardless :) :-) > >>> 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. >>> >>> 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... >> TBH, I don't think we need to make fault handler more complicated, it is >> just handled as anonymous fault handler. >> >> I understand your concern about changing those vma filed outside core mm. An >> alternative is to move such change to vma.c. For example: >> >> diff --git a/mm/vma.c b/mm/vma.c >> index bb2119e5a0d0..2a7ea9901f57 100644 >> --- a/mm/vma.c >> +++ b/mm/vma.c >> @@ -2358,6 +2358,12 @@ static int __mmap_new_vma(struct mmap_state *map, >> struct vm_area_struct **vmap) >>         else >>                 vma_set_anonymous(vma); >> >> +       if (vma_is_anonymous(vma) && vma->vm_file) { >> +               fput(vma->vm_file); >> +               vma->vm_file = NULL; >> +               vma->vm_pgoff = vma->vm_start >> PAGE_SHIFT; >> +       } >> + > OK that's more interesting. Though the user-facing thing remains... > > It's possiible we could detect that the underlying thing is a zero page and > manually print out /dev/zero, but can somebody create a zero page file > elsewhere? In which case they might find this confusing. I'm not sure about file mapping. However reading an anonymous mapping will instantiate zero page. It should not be marked as /dev/zero mapping. > > It's actually a nice idea to have this _explicitly_ covered off as we could > then also add a comment explaining 'hey there's this weird type of VMA' and > have it in a place where it's actually obvious to mm folk anyway. > > But this maps thing is just a killer. Somebody somewhere will be > confused. And it is not for us to judge whether that's silly or not... I just thought of named anonymous VMA may help. We can give the private /dev/zero mapping a name, for example, just "/dev/zero". However, "[anon:/dev/zero]" will show up in smaps/maps. We can't keep the device numbers and inode number either, but it seems it can tell the user this mapping comes from /dev/zero, and it also explicitly tells us it is specially treated by kernel. Hopefully setting anon_name is permitted. > >>         if (error) >>                 goto free_iter_vma; >> >> >>> 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 :) >> It does reference a file, but the file is /dev/zero... And if kernel already >> treated it as anonymous mapping, it sounds like the file may not matter that >> much, so why not make it as a real anonymous mapping?  Then we end up having >> anonymous VMA and file VMA only instead of anonymous VMA, file VMA and >> hybrid special VMA. So we have less thing to worry about. If VMA is >> anonymous VMA, it is guaranteed vm_file is NULL, vm_ops is NULL and vm_pgoff >> is linear pgoff. But it is not true now. > It's about user confusion for me really. > >>>>> 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. >> As I mentioned above, even handing back zero page should be not needed. > Ack. > >>>>>> 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. >> Sure, hardening the VMA initialization code and making less surprising >> corner case is definitely helpful. > Yes and I've opened a can of worms and the worms have jumped out and on to > my face and were not worms but in fact an alien facehugger :P > > In other words, I am going to be looking into this very seriously and > auditing this whole thing... yay for making work for myself... :>) Thank you for taking the action to kill the alien facehugger :-) > >>>>> 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 >>>>>>