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 3A459E7716D for ; Wed, 4 Dec 2024 21:25:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 911676B0082; Wed, 4 Dec 2024 16:25:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C0156B0083; Wed, 4 Dec 2024 16:25:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 712876B0085; Wed, 4 Dec 2024 16:25:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4C27B6B0082 for ; Wed, 4 Dec 2024 16:25:28 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 03C92A11E4 for ; Wed, 4 Dec 2024 21:25:27 +0000 (UTC) X-FDA: 82858557768.28.2F84BCC Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2042.outbound.protection.outlook.com [40.107.243.42]) by imf10.hostedemail.com (Postfix) with ESMTP id 88E27C000A for ; Wed, 4 Dec 2024 21:25:18 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=UYTvSfyP; spf=pass (imf10.hostedemail.com: domain of jhubbard@nvidia.com designates 40.107.243.42 as permitted sender) smtp.mailfrom=jhubbard@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.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=1733347508; 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=08qBHPBBlMkczhYgj2q/B6OWIajTyM7o5apZtWATbns=; b=poVGVOfKJNSuuLjR8tbkHc9OmSF9JLLnMagC1Tm5hRtoKWN6d/sE5uJ0TdCEFGku5MUpmw dnHj3K5SZf9JCgQ4hqa/lHP/AQWAbT8GeKy919g2r4ix78YsTVoLsI/2GSWVPLiorjBSsi iC6Ai8vvXTBZg/svXboQcDtFDgHABUs= ARC-Authentication-Results: i=2; imf10.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=UYTvSfyP; spf=pass (imf10.hostedemail.com: domain of jhubbard@nvidia.com designates 40.107.243.42 as permitted sender) smtp.mailfrom=jhubbard@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1733347508; a=rsa-sha256; cv=pass; b=jt05SphvxbSA3b7LCWbx8zGTrmbAnKIJ9728CkgPihnVMUhK8S0jO8yy0/sTqfEPxPUUfv DB9xefialIjAoygTrCSJiX35cVxs8Kz5vA2sL8s7ut00vEilo9Vp70XGt1CB+ETz6wX6v6 XjhKvqm8CThml+qYjIkwfXlV4FK+Fsw= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nMOO30ug6AMFkJcXQbWHn7CWkgOC5CbkQNkdobnGyZGvLTxGpdF1ifxC1RJwDizYK1oK663yD7wbQdaYNicv4T8lWoNH3nQxRajLTCfPF/NARTe77if9aKKQcloUp9lh0/Sda7BhyaupGdP3ZkGSZIkqAjxEepXl0R7/WfNNggSYKFWhvzbQVdHz/DAWYXNjw5C7Z/C57W7As77AsvfZto8DGBJ+hPQEwjFpTpZ9T1lm1Q+7row9oQBglcOX3c5OgZzSgLTyaLka3GcPMUe5ScOvOKdRCnWwJj67A3KPYzs+2LqRBHVF5dFJOQtnw04feTW6xcJAXmhcA8mY78Ym1A== 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=08qBHPBBlMkczhYgj2q/B6OWIajTyM7o5apZtWATbns=; b=NL+yK8P7tIwsrmDKrTfysp9DDflvhRSmnDTHiCQgxYdNoU48D5ggr26Wg3qxSjvjJSo+FTF6Uaf4tjkLPMBPujOm1Ka97tfEI9W0cUQ7Zm+MaiLTpIJ03CuqjFoibQlF9AQTVYJIWYkBFGgm9H+3XbM7L0D7wD24vXxD8hx9v5FHbTdmKHloSOYHk8KfJumXoBF2hckJItdbkiNeDiRql6ZrZmrSNf0QAL/B0drPnmQ1YaYuSB1eCpYQtXoLtGNN5z6SsWzwv8BGrjYwr+oF1trSpPyRwNvLs7VVXRRqFaizrwG1k5/Gi7TvvQ3yzQG9niIQUVp/QZGPR/CFk9veQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.117.161) smtp.rcpttodomain=suse.cz smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=08qBHPBBlMkczhYgj2q/B6OWIajTyM7o5apZtWATbns=; b=UYTvSfyPvldHY2kgZfWYN5YLfYz0kvCJgm41V9vrCByC9W+D7giiNSunznqmHP/Ivc6y64TpKJpn9/JVAClyj0bQf2XJxzSPPPplpi+c4Czp7je6ekhY0Kn3ghkkI+THVT3+oxYsnyoCSyM6n5bgY111/ByC4ZU1yMpXX7mW0I3Bv2+5durUbKMuCMhDAndjHzvspKGri+mDW9yTBOPHhRS9Weh5KV6ppABNc7bAhzA0EqwP/Pu4hFFv6XczlgKLF8M4BRBIN2KzRytoz48Sumqiu1udryAcL7R1Fwo0Nbv+Vs27+w/XbZfavnZgxe4/JFaTVqh5neZ0LQ+vbXfI+g== Received: from BYAPR21CA0022.namprd21.prod.outlook.com (2603:10b6:a03:114::32) by CH2PR12MB4118.namprd12.prod.outlook.com (2603:10b6:610:a4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.15; Wed, 4 Dec 2024 21:25:13 +0000 Received: from SJ5PEPF000001D7.namprd05.prod.outlook.com (2603:10b6:a03:114:cafe::66) by BYAPR21CA0022.outlook.office365.com (2603:10b6:a03:114::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.6 via Frontend Transport; Wed, 4 Dec 2024 21:25:13 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.161) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.117.161 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (216.228.117.161) by SJ5PEPF000001D7.mail.protection.outlook.com (10.167.242.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 21:25:12 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by mail.nvidia.com (10.129.200.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Wed, 4 Dec 2024 13:24:58 -0800 Received: from [10.110.48.28] (10.126.230.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Wed, 4 Dec 2024 13:24:58 -0800 Message-ID: <512db7a7-9971-4db0-b0f1-f6ecfffabf7c@nvidia.com> Date: Wed, 4 Dec 2024 13:24:57 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: avoid zeroing user movable page twice with init_on_alloc=1 To: Zi Yan , Vlastimil Babka , Kees Cook , Alexander Potapenko CC: Matthew Wilcox , Geert Uytterhoeven , , Andrew Morton , David Hildenbrand , Miaohe Lin , Kefeng Wang , "Huang, Ying" , Ryan Roberts , , References: <20241011150304.709590-1-ziy@nvidia.com> <9942C08D-C188-461C-B731-F08DE294CD2B@nvidia.com> <09B2AB6A-B122-4287-B97E-F800E511097E@nvidia.com> <2390F919-D502-4428-B8CE-5154D30112C4@nvidia.com> <2D6F1B31-A261-4983-B0AA-D45C07E21CFB@nvidia.com> Content-Language: en-US From: John Hubbard In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.126.230.35] X-ClientProxiedBy: rnnvmail203.nvidia.com (10.129.68.9) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D7:EE_|CH2PR12MB4118:EE_ X-MS-Office365-Filtering-Correlation-Id: 453f0162-a808-4ad5-84b4-08dd14aa2357 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|7416014|376014|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cHkrK1NTaEwrdlc0ait6QkUyV3pzT2YwMkdlc0lxMm80aGtuVTVqY2srRUp4?= =?utf-8?B?M2ZUOG1ZclNBOTRtYlhnSmUzQ211cERKWTcvbFZINGtOdjZhb3U2N1A0NnNH?= =?utf-8?B?L2FGazZOcGsxRmJUNDlHYTRTMWFZcndpM2U4cGx2cFBSaWJvOVVraURZclpM?= =?utf-8?B?VTJ3RFU3UTdWbk8wTDh0YWJoVzRkVWV4Q3BpUWNJNGN0NjI2bWxhQWx1ZGlX?= =?utf-8?B?NVBhSWkyQy91TThvbGd6R3l0c1ZSeGtRbzhzc1F2T2V2TnRiL21yWlZCVlVJ?= =?utf-8?B?bFJkTTB2dmpHMzRadDkraGxlZFowRHdSZXZJc0lsdzFkby9LRXkwZ0lYZm15?= =?utf-8?B?Mlp2MmhRZW5vQ2lKUTlIU3hzU1REWTBUdTBSUzk3dzQvVzMwcFJsbDQrMExP?= =?utf-8?B?MU1iaFNhb3JDMFFjN3k5UUpwWk8relFVeHppRGVIQi9vNWpIczJ1L3hyZ241?= =?utf-8?B?My8zd3lXNVdoNHhLVVBzWnMvMUlZZE92WVJ0WW9Zck9FU2pBSHZuQWRzbkIv?= =?utf-8?B?c3pjbk1WZlhnL0RNUXUwL2NlY1JURVJ1b3hGL0dvSXljZk9uRGUwK0hjSnBz?= =?utf-8?B?Nm9TRDFKbFprMHlhNHVUL2dhMmlXNUVoREVrQkFVZ2hOYW9Ldm5ITENNNS9v?= =?utf-8?B?b3NqSG9jbmVCTWxLUkIxWSs0b2hSQW1KT0RvVG1BYWI4QU5seUR5TmpLTjZV?= =?utf-8?B?cjFRYmlPNWNQL29IMFhYTDhFMU9pYUZWWHB6V2hnbzNKYmZibVZZeUpUcXBq?= =?utf-8?B?S20rU1ZFMzBzUGhGZTlWbENuZUwzb2FZL1BLcWRDZ1lRWDh0M3BHV2hFdGZj?= =?utf-8?B?aTlLeXAvSVp0bEdpRC9nU2gzS3JRMWg3NWk4K0lra3d6Rlg3M2hxQWFRUFZK?= =?utf-8?B?OHlwUjlhNTNvZ2NCeGYvWWJVK2tMWTV1YVcremh0eVVlU2QwWXJFL2Zzc01J?= =?utf-8?B?WGE2OUl4VE0xcUEvcVlPTnJvcmdYU0RtaHN5WFgyclVEMGhza0tiOHpBNWdG?= =?utf-8?B?NWNwUXBoY1VuRVpyckxQMUx5YUlCNGRJelJOZ09PcllGTGI3T3JXbWN6L1Zn?= =?utf-8?B?NDBjd2VBSXQxMHJpaE5EeE9Fc0loVGhxbG1UaGpWeno4dm5QUEVvMXBUTEVM?= =?utf-8?B?VGF1S0hkZkZmcENCTEIzejRLaGF3TWFrK1ZDY1V3NHdKbVdTOThMbFE5bFpn?= =?utf-8?B?Vk13WjhjRmsxUzZ5aStyeDM1ZGUxdWV1akRXUExrNG9ON1ZMdVprUjNhM3l1?= =?utf-8?B?d2N5MzhyTlhqYVkvNk5pcGgzc0N6ZkZjeHZSM3hyeWEwbVdLRGRTakVIL0kr?= =?utf-8?B?YVNObmhDNysrK3RyK2ZRZTR4eGVFWW1hQzIrQUFUMkJzUUxSR1E0UXlORC9S?= =?utf-8?B?Z2lkeXNjaU5SMm1iVFVZUEpKUmVHTEsrcS8vZGJHS1VzSmxrQ2FnYlFjSkFU?= =?utf-8?B?bGJ1dmhCdFRNWW42VGZkTURQVFd5aW10NnJBRGVBL203TXFFWjBTS05yOFZ6?= =?utf-8?B?dXNBL0MyVlgzKzhHSTIvSFdZd2k2b2NlWDI5clhHNENJcmxINkZiUG9yVWlm?= =?utf-8?B?NlF3U1hKWTJxM1JYK1pvUEd6Yjd1bU1VSGI1QzNBREFublkvbmZmQ1h5Y2RY?= =?utf-8?B?WnRZS2pJUjBkMUpOa0RkbTdtaVJXREFuQkVRZlo0aFBUUUh4VXJXVmp5Vkth?= =?utf-8?B?MDhCT0xwTkRoMklaaG9xUncwVnJMVWRZcUpaYktJV0c3S3pMZ21hOWZHZFZO?= =?utf-8?B?Rk5BN0V4ZXpsYmlSdXpKTGVJTmN5bVhJWDVFODNXc0ZhK0NVWmpwdlBYRExO?= =?utf-8?B?bUczR1FkZnVjakM5UVJ5bUU0UXNPak5xczhrZWt6eXFDOHJNRjlxMnNpMFNz?= =?utf-8?B?ZklSQnJHb2xsZWs5aWFiQ2xEVXd5NXZqM0R3ZGxVOTI2eXJPWkxDOFp0a2w3?= =?utf-8?Q?K0E3Lb1k38VfmacJzhovm3h061zNykUu?= X-Forefront-Antispam-Report: CIP:216.228.117.161;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:dc6edge2.nvidia.com;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(7416014)(376014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 21:25:12.5318 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 453f0162-a808-4ad5-84b4-08dd14aa2357 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001D7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4118 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 88E27C000A X-Rspam-User: X-Stat-Signature: qxtxjmt8sm1ntdqaaphntwkd37j8qtm7 X-HE-Tag: 1733347518-440854 X-HE-Meta: U2FsdGVkX18vuyK4FsrVseFzvR+LNDp5e2WlwpS/OajOy5TcjIu3NgtG0zzV0jAOHc3Mc8iwVwsL0Wuw2TDQi0kIsXNUsLQpBReyZSG1fALeDxJcucMYvukbCmKBDcT+2vF0zAhPt/IRDnhcTHk34g+xGmsg+XVpdpZhdUe5FbPtD5auWsOH96djJXi6pYNgx9uDeP2xZo8X23L2J+H5D/o1EehZCxK1pm+eD9nUlExONiOgP6jEReXwcLWOGLMFjorn/pp6Zi3nWIGFkJLQ2MkEzrkyu3qFCs5ZTuBeX/YGY7slejhi0FQ2W4/btc8j12jlaanD9L2esLPrvJ+qvxibZKPtZ0vZZwoMFPuzC6okEVbk9jGu8h+lhgak4Rfh39qRRAOacc8BWPz8clW+Kr+zglrsk0te6D2tRJDlUzXaLCJcff6fWEbiEK6p+28a+bp1MNFQ653Hs7XHh0xIkcoATRFH3CQkCFXMYmbzX3oR4hgAp6gRqbdw4HOeuGvprXLbyLu6+uieiqRIkIyQCXZFwr2zKwMJrZjd84DWkWS6HDKy9fuyJXKimOm6T+lk7P0MOu7s3ko4XNoSvXNgAgUmM9Emhw6lDpfQM0vWdenWW8v8IVrAHjLOEIv3hqm+WnIcfHwwslxS5sIdcxiOW4QZMISa/FJPP8L8yYvfKWrhg7RCMwo8W4IxoD6Db94YHl9bBC+U8PXinqrhtr7GUw42qSEGpNPZoX+1u73E6OZ2wKHeM3lBFl46VDTwjtqWAedWKxSYINzX3WNz9+8hVPqxUhbQ6HeiCgR+Yi0eStZOeT6vAVtU3X0EHlweN4j7UDllPM4WNoUhNJX2UWypUabxNNZf+VF9L34uC9adyxk7r0JwH1s6dYjAerNGXfDYWPN1EdO/xt1m/pVTN+6vi49ZWrs71nmMEeAFwDGQLaoNWjOJhDHY6yU2l/J32Dr9jmtyA7xBrSex2blWMJ5 eEmNqyP6 jwr8a4PhHIQgcPwQF1OoUx5BPXosxyY3LddM+VybLUVw4kd/zc6iJv6EljBLz/w64CSdctX/BuGlKLlYVa1olsAhxbVi20nSyiInhp+ntiryaHTqEsawXbPq81uhaO73gZqVPijD2MqM5o4KkzfL3iVUXtVf3/1/MVYtRl+ShDaLE4eUHNJovsmg5XBA8tLr8B9NEoO2XejWAINrBTKOGHBmFKMaSNgWMzcAOFYpUMU2WeuwKHNU8bDH9fW8kzRNAIlv9LHcVyVFZ5TO3xY5YH43ICCwxY8rly0QxvNUeIcGBa8xDqpuGGnuBh+sUVFF9AXNdozPl9jcLPbW/tB2bGGatbdcGRdrE1x5ItLrK3R4n4VTRGT9Luc7R2zDJuYIa7EmuUmlFTfgkmFGpHovZPMnbINL4AXC0qrm8292Pn69+Cij3PwT90ka9Kzi0xPIZqYjHcXUa5k8vT3Rhya9+kDUBJQ7AohlEvD+d39gYGSpTru/ue9QJyZWbsmFCwWxT3+6oePTE9517WA22qG9bIcyd0H1Qwgh8xmsIHNvWAXU31dt5qJmuXbsnWh6yBkIsMp7e 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 12/4/24 1:21 PM, Zi Yan wrote: > On 4 Dec 2024, at 13:16, Zi Yan wrote: > >> On 4 Dec 2024, at 13:13, Zi Yan wrote: >> >>> On 4 Dec 2024, at 12:46, Vlastimil Babka wrote: >>> >>>> On 12/4/24 18:33, Zi Yan wrote: >>>>> On 4 Dec 2024, at 11:29, Matthew Wilcox wrote: >>>>> >>>>>> On Wed, Dec 04, 2024 at 11:16:51AM -0500, Zi Yan wrote: >>>>>>>> So maybe the clearing done as part of page allocator isn't enough here. >>>>>>>> >>>>>>> Basically, mips needs to flush data cache if kmap address is aliased to >>>>>> >>>>>> People use "aliased" in contronym ways. Do you mean "has a >>>>>> non-congruent alias" or "has a congruent alias"? >>>>>> >>>>>>> userspace address. This means when mips has THP on, the patch below >>>>>>> is not enough to fix the issue. >>>>>>> >>>>>>> In post_alloc_hook(), it does not make sense to pass userspace address >>>>>>> in to determine whether to flush dcache or not. >>>>>>> >>>>>>> One way to fix it is to add something like arch_userpage_post_alloc() >>>>>>> to flush dcache if kmap address is aliased to userspace address. >>>>>>> But my questions are that >>>>>>> 1) if kmap address will always be the same for two separate kmap_local() calls, >>>>>> >>>>>> No. It just takes the next address in the stack. >>>>> >>>>> Hmm, if kmap_local() gives different addresses, wouldn’t init_on_alloc be >>>>> causing issues before my patch? In the page allocator, the page is zeroed >>>>> from one kmap address without flush, then clear_user_highpage() clears >>>>> it again with another kmap address with flush. After returning to userspace, >>>>> the user application works on the page but when the cache line used by >>>>> init_on_alloc is written back (with 0s) at eviction, user data is corrupted. >>>>> Am I missing anything? Or all arch with cache aliasing never enables >>>>> init_on_alloc? >>>> >>>> Maybe the arch also defines some hooks like arch_kmap_local_post_unmap() ? >>> >>> But this does not solve the possible init_on_alloc issue, since init_on_alloc >>> is done in mm/page_alloc.c without userspace address and has no knowledge of >>> whether the zeroed page will be used in userspace nor the cache line will >>> be the same as the userspace page cache line. If dcache is flushed >>> unconditionally for kmap_local, that could degrade performance. >>> >>>> As for the fix, could it rely on e.g. __HAVE_ARCH_COPY_USER_HIGHPAGE instead >>>> of CONFIG_MIPS? That affects more arches, I don't know if we broke only mips >>>> or others too. >>> >>> Yes, this is much better, since this issue affects any arch with cache aliasing. >>> Let me update my fix. Thanks. >> >> I notice that arm64 has __HAVE_ARCH_COPY_USER_HIGHPAGE defined, so I will >> need to look for an alternative. > > It turns out sh, sparc, arm, xtensa, nios2, m68k, parisc, csky, and powerpc all have cache flush operations in clear_user_page() compared to clear_page() and > arc clears PG_dc_clean bit in addition to clear_page(). > > So __GFP_ZERO cannot simply replace clear_user_page()/clear_user_highpage(). > I can add ARCH_REQUIRE_CLEAR_USER_PAGE for these arch and use it to decide > whether clear_user_page()/clear_user_highpage() needs to be used regardless of > the presence of init_on_alloc. > > I also wonder if INIT_ON_ALLOC_DEFAULT_ON works on these arch or not. > Well, I've been waiting to point out that if you actually *delete* the entire INIT_ON_ALLOC feature, you'd be my personal hero. Defense in depth is nice, but at some point, it crosses a line into the absurd, and I think we are there. :) thanks, -- John Hubbard