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 D947BC021A0 for ; Mon, 17 Feb 2025 08:08:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 560D96B00BA; Mon, 17 Feb 2025 03:08:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E9706B00BB; Mon, 17 Feb 2025 03:08:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3636F6B00BC; Mon, 17 Feb 2025 03:08:00 -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 143EE6B00BA for ; Mon, 17 Feb 2025 03:08:00 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 414E9121E1B for ; Mon, 17 Feb 2025 08:07:59 +0000 (UTC) X-FDA: 83128708278.03.692D81E Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf13.hostedemail.com (Postfix) with ESMTP id 4C9732000F for ; Mon, 17 Feb 2025 08:07:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739779677; a=rsa-sha256; cv=none; b=dwM08G7R34ymgrjVpDpY9ZU6VeY0jvcBI3a6HvYDYJO2jIWTD7ThKVhasDR4OIQqmCmJJd pfsMtBs6jsAF8LBKjMmWrEBm5EPLgOcy8NX210Gvu5eDzkZsAZI4+tdMjwntB2+JOKsNeH oNcDrSy4NHnm0idt3NfL39P+7NH9y/M= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739779677; 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=qcLmadiNH84yKe/L4JYojk3Qejz7s9KQF2cXf3WqfYU=; b=5HjZ4eeDc3/ZcqskYO50xijCd9/J6rZDgxBXfO71mVnp3qLxK65sixcJ/eDEYLB1QNa6ON +3CZLhlUd6JaG2VZtUXE23moN+VkBrOc7kJBrAHv6JbkpIxTRgI5C4OJRLkTloBOUwYz0p M51Hcj/OjIL6kK/8ZaXCUcLbAS9vuWo= Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4YxFXw2mFXz2JYY6; Mon, 17 Feb 2025 16:04:00 +0800 (CST) Received: from kwepemk500005.china.huawei.com (unknown [7.202.194.90]) by mail.maildlp.com (Postfix) with ESMTPS id 765EE1A0188; Mon, 17 Feb 2025 16:07:52 +0800 (CST) Received: from [10.174.179.234] (10.174.179.234) by kwepemk500005.china.huawei.com (7.202.194.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 17 Feb 2025 16:07:50 +0800 Message-ID: Date: Mon, 17 Feb 2025 16:07:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage() To: Catalin Marinas 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 , , "H. Peter Anvin" , Madhavan Srinivasan , , , , , , , Guohanjun References: <20241209024257.3618492-1-tongtiangen@huawei.com> <20241209024257.3618492-5-tongtiangen@huawei.com> <69955002-c3b1-459d-9b42-8d07475c3fd3@huawei.com> From: Tong Tiangen In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemk500005.china.huawei.com (7.202.194.90) X-Stat-Signature: d8xhk36894im6j81ew3hgfp5copoauka X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4C9732000F X-Rspam-User: X-HE-Tag: 1739779675-685833 X-HE-Meta: U2FsdGVkX1/s+6M7fHxl1OBRsNLH2hOEXv2onwKtBP+qZ9oNYNhnsZaAC7L/j0r3uivTcFzJyckHpIIPyQlIG968OnzTpCg7l4IKey1MSIAwBhFNGuRiXZn3PXK++AChLJsC0IxrLHr1OaG5Hn7YBCooJcFRCdHlU9X7XoGEYn8CZw0KqDk4kJxxmjc/FbiPItCZCPbrNjlqYJhfwE48nktP+ErPzsfSQ/s9+r5BD6mITCBhcmzizpz9nJbuWNB8epCh9PT/M0djJYcJ1e4GW4IMtPNd4VYu9at+wFwG0M3uDcVYDN+EJ1QKgbKv6t8ff4+nnh7waNhY7CKG1OH8Xb9Xso4gNYzxisaDq74IfcClRgsbLjosxhfjejvrc+Z6wVQCUzOYWZRTYU5849iO/fc+iyjly7sRKs8YImOhhg56WfVNCOlFhQt6SxzmeHEvR0ehCBqtuyogL1c17zNTbd/ys2NHqqicSmrv6kQt8Z1w881hPHkc7I3f74jlI2/P6zzAUWW1QNeGgXCt2uZzlYqpDojPAHHQ8Y9oiLuFRTc2GvLGzsW2bs7CFdoYtkFC9KW5ORd9v2gUljh+X8rw+ZCqM39SWMri8wDPPUkUgeEn/BdhukqhHZB54O+fP/Jej4hgDUZFYMippvlAWCNQcpWJo92MW9/3gbCrKNLnr2qYWzMXYAH8CYsKYhW3DejFEwbQc+PIuy04DRgjsbafwzJoo7W+1QYrpPUDNYPwqGwKxYIdmlWRsr59g9lgWoFTrJSx9kr1+7hxbt3aAs7eOGj7dqZ0DtRE6AQ+et8PV7D4EoIhJrNJqh1JK2uUuibYwlssY7Ne+yj1Ei52AkacByOSrEtcXUNr+skpCw5VUE4d4ZE909Lqr5BDxXpEsnW2Ojnli6bEyw4iDdM4wiwM4feO9r+WNIs6z3WQNLMGUIKH4kkSewYHEXQjmAQgO9iw747wHpIxbehob/eFlGL KXyyb6hC JbB0cEy1DDbzP98upc/sQEq7L4C6R/yV+y5C21b4K5Fn+8z2rNVSDVvaXi3i/7LRcUJ1Ovvd9KBBjOhPD6uHgYtk2ZahilbGyrj/vxK/H66xUfAIqIdRYzjVgzjmWcSgzSVgXWzp4FGJJYKgOGRuk7JDP3QhGAqCJfyppsOOfUHOkGcHPdr1ZJm3aXI7Zf5FC0/z++zCi18idIUMP8YazSHwPd8DGUhmsHjTuuQ8wG5Te06HxC7q5bpRt7JKKTl7UQkEbqnLe30CyEFhEJ2DiYlTU+w4IcDIBIli7 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: 在 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? 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? Thanks, Tong. > >> 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)? >