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 32C0EC021AF for ; Tue, 18 Feb 2025 19:42:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB5C4280197; Tue, 18 Feb 2025 14:42:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6627280193; Tue, 18 Feb 2025 14:42:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2E36280197; Tue, 18 Feb 2025 14:42:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 82635280193 for ; Tue, 18 Feb 2025 14:42:52 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2CB77C04A5 for ; Tue, 18 Feb 2025 19:42:52 +0000 (UTC) X-FDA: 83134088184.20.21A9A88 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf14.hostedemail.com (Postfix) with ESMTP id 802D510000F for ; Tue, 18 Feb 2025 19:42:50 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf14.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739907770; a=rsa-sha256; cv=none; b=4HuJKLog6TeHfzzclO2XSVVIrV+2m5HwvJkHYWUtzBVhldw0ma+OQQ/XNU6lmLQQZI69Rx h0YNUA/xontdQITOASNvnPfgqGi7GNr92i19fmuA+HLtuYldcI1O0fuDcZP26Il38/XA4+ YyB+ZvGeYTBwWhJvCF4DXG/+NYE4P/s= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf14.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739907770; 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; bh=l0OefYp6gIJsoBkqWu85YVPRb1yh3g60mRPL0+SvOSs=; b=ef3iwQzeA64UKu/MAs+87PuHWSqqZERTMd3J39AgZufnAHUDgG0+M2jc0YCl/euaaQ1zDD 8cEvh6qclmGBDhl5k3HM+nYfzlcoo2hr7MtYltXlim2Sze8SAFy0USGRwNWPfZUTc8j5z+ m12eLVPNcenD5mum32Sd9qqVdBrhsV0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E0790A414A0; Tue, 18 Feb 2025 19:41:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 637C7C4CEE2; Tue, 18 Feb 2025 19:42:44 +0000 (UTC) Date: Tue, 18 Feb 2025 19:42:42 +0000 From: Catalin Marinas To: Tong Tiangen Cc: Mark Rutland , Jonathan Cameron , Mauro Carvalho Chehab , Will Deacon , Andrew Morton , James Morse , Robin Murphy , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Michael Ellerman , Nicholas Piggin , Andrey Ryabinin , Alexander Potapenko , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Madhavan Srinivasan , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, wangkefeng.wang@huawei.com, Guohanjun Subject: Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage() Message-ID: References: <20241209024257.3618492-1-tongtiangen@huawei.com> <20241209024257.3618492-5-tongtiangen@huawei.com> <69955002-c3b1-459d-9b42-8d07475c3fd3@huawei.com> <3b181285-2ff3-b77a-867b-725f38ea86d3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3b181285-2ff3-b77a-867b-725f38ea86d3@huawei.com> X-Rspam-User: X-Rspamd-Queue-Id: 802D510000F X-Rspamd-Server: rspam12 X-Stat-Signature: 8bxpd1187pjfzdi9co9td1n6ise7it6x X-HE-Tag: 1739907770-21520 X-HE-Meta: U2FsdGVkX1+oD90mD0mWs1hs2y4auC8QIJQGWaCt/gpMrsIRxFw5tAgD6JRuZC5EqgXWUUKlU5KIAcm0SkoRBBfD7Xrc+4JK3fA2dX/rus32MrwAzXHxBT0tqGy3AlNziJekK1NffKbEptPAlgRnAYWSJxl1ZxBF9JbE1kXvzxA67IUlNA9UA9DEQ7C+Dey7PzLftUkFp3n0fSXRKyjlXg6rVDdz/x4I/XdWrbHCf73ddGYyZHOQqWrRQo1IzmPHG/fdHl/vVe2qRmDJorc6dPAHDyF9qqXFSazUNUCObEYQzub49EBWLrARRPAkeLWbzr8cE4mvjIpvAveWpaNDTANx8+eZojrX3ZPkfSOZWr5CqsnUxZJY5VQ+xw2bCpZ8M+eyBOJHhuz+h7z7gncpXEKkPeY5xQNu9Ia8bXY8xq1diuTT/BVh0T85Lqg0Hl/ZlJjDBkkqEPP/3Wj5MxxYJtdydaYOMwxJ/VlrbPMHh+KYPXG8TkUJFADWYP9rQLP0jNK/Pfm6mIyEldzAMueig4E5UeRP/0gUUHSgifpJKOxNy4JeT0txY39vAfs0G1fx5Qt5BZ2PlUMkox5tz1jUwjYNfZrUf2bv83gErNCNUePSpZdIdqQ6jYr5fK7usYu8P7yMYAnjbi0vYYFKY/NcsJu2Gqu8AnWvOMFyq9Bc8VcGYCWwv4U1Wsw44/3tr09vJVVsycejFlxhWHqaWKZV1gY7iPOVTOGSJ+NvPhlZgNBV3EybFVwUl2hbEitRPCnfigayTeEfprUQ8kM66LNxdem7RCh/BZj6bXubn2ahuRLvDINcIPSR6UI7uR4giNDWZ7qCLTIMdwWJ8RMxkEcFJ5w410uj6Euvy1OW0YEEpaX1Xu5WjGDDwMvzC4MR6V6jUlz5JE/gb1qsG8g5+Xzax8AlNv2iQe/fPlyzbKQKPd5z2r3BY1RSFrHb7j+2Ce/071aH3aY3Xzs9CLndAEz WNYYMFF6 PSOsQutIZFn/0VkBBRK37wKVnS1zGLrYrhRmxR2szl8lTCbaAIEEDahzWxIt/9FVt0itOouuGcrx85/5WaEP9Dyc8d0c+EBbWHxmN/8/ryWZ3UhLGhyCbeygn6TtmsHsqOK59Y6zXOTEf3vcvmioBMCG4qToTwqQIBAMkGMOXb0SfEGjYB3DVQf7bo2SswLXgjHJzc4hZ43/I3TnEe4FBTZlE9nGIAjC6IS3BlaYhbIiIphQrWCzGQ0xUlOuPZw/vtUwJSCUYQJ7s9oImt1rcPFfqYDJAN3PcohFZ/SQo5A64QYxl3vKBmoLKoDZKadAezo2kH8L2BScqLlIcd+WY0YMA8Ezb0sPkg13CfO1Wh+6D7WhEOY1Ww/giDltga+5eoKBdozHgUzrK3Eh3dgNozc5JJ0r3VbPiB4WgK3Cse687j8XHJSTbaJe9P5M/zFijYfqlc4CSyLRwiNwtUo/YtsQbphti6j3e0ejLAGiopYjgShKPTwrwOK4Qvw== 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, Feb 18, 2025 at 07:51:10PM +0800, Tong Tiangen wrote: > > > > > 在 2025/2/13 1:11, Catalin Marinas 写道: > > > > > > On Mon, Dec 09, 2024 at 10:42:56AM +0800, Tong Tiangen wrote: > > > > > > > Currently, many scenarios that can tolerate memory errors when copying page > > > > > > > have been supported in the kernel[1~5], all of which are implemented by > > > > > > > copy_mc_[user]_highpage(). arm64 should also support this mechanism. > > > > > > > > > > > > > > Due to mte, arm64 needs to have its own copy_mc_[user]_highpage() > > > > > > > architecture implementation, macros __HAVE_ARCH_COPY_MC_HIGHPAGE and > > > > > > > __HAVE_ARCH_COPY_MC_USER_HIGHPAGE have been added to control it. > > > > > > > > > > > > > > Add new helper copy_mc_page() which provide a page copy implementation with > > > > > > > hardware memory error safe. The code logic of copy_mc_page() is the same as > > > > > > > copy_page(), the main difference is that the ldp insn of copy_mc_page() > > > > > > > contains the fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR, therefore, the > > > > > > > main logic is extracted to copy_page_template.S. In addition, the fixup of > > > > > > > MOPS insn is not considered at present. > > > > > > > > > > > > Could we not add the exception table entry permanently but ignore the > > > > > > exception table entry if it's not on the do_sea() path? That would save > > > > > > some code duplication. [...] > So we need another way to distinguish the different processing of the > same exception type on SEA and non-SEA path. Distinguishing whether the fault is SEA or non-SEA is already done by the exception handling you are adding. What we don't have though is information about whether the caller invoked copy_highpage() or copy_mc_highpage(). That's where the code duplication comes in handy. It's a shame we need to duplicate identical functions just to have different addresses to look up in the exception table. We are also short of caller saved registers to track this information (e.g. an extra argument to those functions that the exception handler interprets). I need to think a bit more, we could in theory get the arm64 memcpy_mc() to return an error code depending on what type of fault it got (e.g. -EHWPOISON for SEA, -EFAULT for non-SEA). copy_mc_highpage() would interpret this one and panic if -EFAULT. But we lose some fault details we normally get on a faulty access like some of the registers. Well, maybe the simples is still to keep the function duplication. I'll have another look at the series tomorrow. -- Catalin