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 AB320C021A9 for ; Mon, 17 Feb 2025 14:55:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2054D28006B; Mon, 17 Feb 2025 09:55:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18E9328006A; Mon, 17 Feb 2025 09:55:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02F2D28006B; Mon, 17 Feb 2025 09:55:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D907828006A for ; Mon, 17 Feb 2025 09:55:43 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 957FDA098E for ; Mon, 17 Feb 2025 14:55:43 +0000 (UTC) X-FDA: 83129735766.23.F10973D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id D589A1A0018 for ; Mon, 17 Feb 2025 14:55:41 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf19.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=1739804142; 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=+M34uV/zkct1kEAaK2pLJ3/QmCI3GfHP6imSRuJbcm8=; b=gpScEQCnlqyMPV4P4K1N0M+6LEJdgXMPVc0meRj0s/+H26d2Wqj1/jIEiGUMxhBFlttFcr NdywAnY47Ji71xfilbN+78hj7SNAQf8p3uM13y7fkHNL2UG4+OFsxG0CL4HaE1eI3qcJik 37gzQHh9KpvWYAHTxMUyN84QTKAwRCY= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf19.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=1739804142; a=rsa-sha256; cv=none; b=M5ng7L7DJwLPVq3pTkyMVxDvCQ9C2hzicdfRhsTOj/B71qKLhrTiDM+5VEKj6OYlNDVYDT v5k70bxpUqlXJrZqLLTiAabhQOmTBzBbwdY5a+2KbpUBpO6m9LcRthTaw6qfbVYW3e5CAL 8fINrfo3petCnPbLohC3ZmoGWjmHa10= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4E9CC5C57AC; Mon, 17 Feb 2025 14:55:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 453CDC4CED1; Mon, 17 Feb 2025 14:55:35 +0000 (UTC) Date: Mon, 17 Feb 2025 14:55:32 +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: X-Rspam-User: X-Stat-Signature: apbnz4tn3bpsi3ghahwh4dk1o9mgqazw X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D589A1A0018 X-HE-Tag: 1739804141-875888 X-HE-Meta: U2FsdGVkX1+HLpR3DPDFjxJLxaWYUSZYmTikANgYprs9jfJg+Mb/5oUwtW54KfvyGniKUhAhWpwjqYNd5vaFc1KcEqQ3cEZSxfeCPYWlAAVOe8h4lle68E0k7a/K67D2PXPhLtreo+Ez+gX1yFCUerVQ3Ozf3R/1lru+O2m1ipDwYe7Llapx7W6okBkGPHt7+HSgbbOXnYgwTlvTKoAEsPBfAKYU26qOfJdNBG0K9jb8Kmya/KAVaiskqZ2H+zqf5v/Xl/Zf6K+nCg1F8vDMsfQwe/nlvkVi+3cfBOHua8EWLazkeG1xfo7xuZKT6cKpFOPHixKZ5K9Le1s3eQ1iuP3/Syf2fKHAYXg+6KNxjl+A+SIaRzp6wY8353bSVBeyFgCcgBPk9ey9/z9nwvUg5q4pk9J9Z/nhc1HUhi7F0lsjDfzpxX6WXtXZv2+Y4zG4TG4DFhuEDkPArce2/k+FbMjVhLk6+hTe66MBmZ1eC4CSH1FCacdNnctxzAgk81VgRGbANvskyNz+5DtVIiYEvzW9pcfITw6byN73NB6uDXONrAoaYm0/YWDAgCnJZDJdC0wQvLIaBS5l55gqdF1LgW/qNR7sHSsqxT77f7gSc+/Sr5HILh9dDzRAflgaluxBCi9WG4KDhjgSO966g9vcTPZnQumroyAzTClSfl3PQSfrr8rz4i01nOOBpmlqKPlz0HJAGHywDGYS+Kev2skdDzrXhgL4gHFShEqsgd+VDYeoWsXg+Rkzy8AThVSfK/WP9zRc6q/JYEAemLMRexBOCVJq/B5uVdc0DOy0z4E2V8sqGSG0gFrHeyTwv3tfNzwUEezPRTOpH7MCO5SIZuJa52T25AZZK0YTFqL/DNU5gE0nuogJa0uabNXYI3m2ZTI+mgJRhVkBxQiFguzFCMxAQxYZzMtmrToGIxnBCJhC2b/0Ad5mn++5fbmN6EPqOxcyT4ta8xf9M5lRraODL4X OwY00bMJ eVHSzUbz5k5aQn6rj4AqlD3jrWJFfNMwIloCvc2HMv1q8UUrCfZDJ4g/QxnQ7ErB7c26CRpOB7HljDVmtbJWvYd84btCsdAjqtXuD6YSMWv8/YH2FzGgXXJVfbCnl0ahmf10MT65WPEsy3LGnTGsFnTkCbMyCd9UR5TIjEuuF0x4pkAR+NyEeffW6IgqF+67wcHMmuLhaQPKM1Z7y9KtyASqyCkDoiwObGsLFy/8mc9B7rX7nVP6TZ/SPRmZCOrKmTXlZqpVbTA0SOFUjYXjzDqF1Peh2y+hO2Yu9o5AZhIj0ny5cTE6Y7WhtYWw5SFk5GMe/gKQRQMu/UO5fSQ0srZ8+B1WmDmSxfqok7UI+ZM5LMSK+rjfDYjgYSQFo9usEwG5MlDmpXrgLVIKAm52I6foHPieVFmUXh6bL59hD5W8zyyWBsI8/mzop4YQhVHnXf9aEp6AWuSYakWpyFRurCAOdVlAmvtNDwh5g8YrKbVO04sVVH0YF60K99Q== 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 Mon, Feb 17, 2025 at 04:07:49PM +0800, Tong Tiangen wrote: > 在 2025/2/15 1:24, Catalin Marinas 写道: > > 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. > > You mean to use the same exception type (EX_TYPE_KACCESS_ERR_ZERO) and > then do different processing on SEA errors and non-SEA errors, right? Right. > If so, some instructions of copy_page() did not add to the exception > table will be added to the exception table, and the original logic will > be affected. > > For example, if an instruction is not added to the exception table, the > instruction will panic when it triggers a non-SEA error. If this > instruction is added to the exception table because of SEA processing, > and then a non-SEA error is triggered, should we fix it? No, we shouldn't fix it. The exception table entries have a type associated. For a non-SEA error, we preserve the original behaviour even if we find a SEA-specific entry in the exception table. You already need such logic even if you duplicate the code for configurations where you have MC enabled. -- Catalin