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 8C4C1C02198 for ; Fri, 14 Feb 2025 17:24:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E42A6280008; Fri, 14 Feb 2025 12:24:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF28B280007; Fri, 14 Feb 2025 12:24:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBA53280008; Fri, 14 Feb 2025 12:24:35 -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 AE853280007 for ; Fri, 14 Feb 2025 12:24:35 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5DFF5AF5EB for ; Fri, 14 Feb 2025 17:24:35 +0000 (UTC) X-FDA: 83119224510.27.2A10592 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id A6607C000A for ; Fri, 14 Feb 2025 17:24:33 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf22.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739553873; a=rsa-sha256; cv=none; b=Aq7UrWzJpE43ujlLmB4rFgoDszxdBoIEP+hNwsgcX1QHQz/dwibcK0pymNqcBNbAUHVeO3 oRs0iaQCc5uSPrCoCTZD8QSHZP0O/kL5Sm4xpePohoKn4PehkqMV+optJjbQb9YPBfSd1O SRrMqby4B4lLUe20uW9e6aYlxq/hIrk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf22.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 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=1739553873; 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=5YtMi32FHQ7+fawZb+ziAVgUu2Jkosuh7gVhJkARHqY=; b=VWnPuJ7coG7oEQbMR96+8u5zq8jQ/C0aTCSEqSOBK+bYTuuWlWXKAv2tMAjO9gR1mpvKUj tpvDjxhG5yg5hqyBWf4XYVPYsSHp927WcxXPAVt7h30+YnaSi4Y7HbvPXPFSVlXmEBpllL nFcEGNhG9V9XOOvEgLHLoJo6WZ6J+cg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 30CE55C5A25; Fri, 14 Feb 2025 17:23:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AF84C4CED1; Fri, 14 Feb 2025 17:24:27 +0000 (UTC) Date: Fri, 14 Feb 2025 17:24:24 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <69955002-c3b1-459d-9b42-8d07475c3fd3@huawei.com> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A6607C000A X-Stat-Signature: 5jgbzw4ecehbga1bwpk36y7r97w7rhsz X-Rspam-User: X-HE-Tag: 1739553873-906943 X-HE-Meta: U2FsdGVkX1+DvXPHSUixkDIPpzZ4SgfjTgpXTEgGlJieOOGYHcu5MnNOqf4QFJx79ZnU878ucfCJOYhDhhY/ZED0ZDQIqTW8g9g+lNytwLMnrjqgfdVgoNtHiCbwQwgJQraDkmYrk6IaSI4I7eFDK1LE4b4vNqmgOqiXBJxUqXGcMfFfAdwdEX+5eluTlv9c1HphQfyvXQoZRRadsHhmpLO+SphhbuAYhh7ROy18OQlBGA7NbK6XH3UVriE9ceZ8odqQnHNehv2/IyCQ+BVU1VpDr1CQJ3bHKZsGwypvGQcijncKKfFOfIgz6kkc5P5a1OAX38lYGkzblxMSsDIW/AzbehDn2RWjQhiyiKq1ygMGOHZkjaRrVah/DqWfVt6TVZmegckfnoQCe8RPDM4I6ef/e1NMblgMAqD4avMJw6Y6Q2bQtHdYmIGWayCf7B7V0mFSkO3WJWxLjnqdDktPjqm/9z2MXvOZSXEjlJ39FwJGehD7lFDaowLlQ70j9b+kOGbo619TU9Sx9Tg8qNFSn1FXzeswOfpkNNbjjmkicogIdvO+HtWbVaLBe1+ztHMeJL413Ajl/JiCl8wVjz5tdEevaIy44n4wah03H3/Rw+iGiY2hh5MWqzerq/wIGmah2f8Zi+cWB40YGE/B4xrpAmrQzdBveEw0SUDZTokcYdfdQIdBOiohxSQvwtHzxit3m57118v/QXqs6NgivqGzrSNOXEjhjGe00ybkNKAxviTuDFQ4jKBXuAPX0ihp39hi6Wynaq3yRq3S4JLRoi1F8Oh9+dvBz4/xoNu0PhyddxiFwXIjBsYMkHKHm31iR+nGNqeqvrCB8VQK/ypJE3CHqBpmKQVKkZBVe5dGPZIKZ6gEuNljORmxGJXjrA2ua1NtGgZRsqPtFHwM1/tSIBGFa7iGhZokkrKWPRLlzLRfQhrlUcBxKhL5EADseSB3Q4rN3PIeqDQEn9ggpr8cwMl 8B/hWAU0 pSV6qIHk+bHRO7ihSUXbELnQ8wR5x6dz/VQLD0C/sSQvnIe1nevbAKRd6AD8OCZ7JVf9PJvgIu4vyfqnw9WleGBNRPhOecG1EWr5SycRFIqfTpqNHQSVv+Na5Efkvy2QCiRGWPChg0ygkeeoSo2VRj7HjDLY9gHl7NPqbQp1wJ7xYvjDbrC3yekXBcpJM6lvdtvZPd8UeL3pXuwVv8ZLBxNvQdevEWszDZM8RP5T0bIencQbt6fkv6Gx0lbvxtHSaGCKSXa2pcqIUfqG0u1/rqhRQoQr/3G3ayWy7h3zC5TiDwTkBWaBOP18xQT9nPr3WqN4pA6YyhwcysSMJ/oDXbRFpNld4CuNqRHFjAtnela7HhbpByhVuj4D6NoRRSbiGovnxEIxf+XsJ2U+1R5mVYjXtO0L32DudbRcJ++2hjsShOB4S8+1YI+6Mm/Dk8gauJFe5rFOhN/qA0J5NL9RFF5oYtZXJNQTHXpd/dE57IGZK63CJ2xrHNf8S+g== 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 Fri, Feb 14, 2025 at 10:49:01AM +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. > > I'm sorry, I didn't catch your point, that the do_sea() and non do_sea() > paths use different exception tables? No, they would have the same exception table, only that we'd interpret it differently depending on whether it's a SEA error or not. Or rather ignore the exception table altogether for non-SEA errors. > My understanding is that the > exception table entry problem is fine. After all, the search is > performed only after a fault trigger. Code duplication can be solved by > extracting repeated logic to a public file. If the new exception table entries are only taken into account for SEA errors, why do we need a duplicate copy_mc_page() function generated? Isn't the copy_page() and copy_mc_page() code identical (except for the additional labels to jump to for the exception)? -- Catalin