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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BDC4EC021A0 for ; Fri, 14 Feb 2025 03:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dAco+YwYPEGkt4T/RB6q+1KKzbs6hySE2tC8jKn0Axo=; b=Y0eQr0x9L4R0O34CE2SqJh0Y70 rOqflytok4pKpH9J7QwDAvXHpk+BNkJDkXwzC1XhOxTs82589Z2P1JspxLGBYr8hw3EJjlz8rEgRX fCGDa/YJNVWCOZ0pIa9cUa0Fy/oc6n3UZLg1/IgMVzck2OCe3snCZp8bb3en+LoDuaJrYXArbr8Wz 23n5q56GMaym0x1CsH3vmQAVSznVLGtMbKK3/mIqX0vdrDWYK4KsHBKYqT4QDd1ZdQ/51XAtTweCJ cKvlDjXRARaZXo5DRnLkvfMt/mO0tLFUZXcPp2qzPdyDsnx4h+5nq6A/t4asDxyE+AWxsVQKH/deu qBSZrSug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1timHj-0000000DTfZ-1Q6f; Fri, 14 Feb 2025 03:22:35 +0000 Received: from szxga04-in.huawei.com ([45.249.212.190]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tiltT-0000000DQQX-30rT for linux-arm-kernel@lists.infradead.org; Fri, 14 Feb 2025 02:57:32 +0000 Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4YvGpC5pGcz2FdSY; Fri, 14 Feb 2025 10:53:39 +0800 (CST) Received: from kwepemk500005.china.huawei.com (unknown [7.202.194.90]) by mail.maildlp.com (Postfix) with ESMTPS id CA35F180044; Fri, 14 Feb 2025 10:57:27 +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; Fri, 14 Feb 2025 10:57:25 +0800 Message-ID: Date: Fri, 14 Feb 2025 10:57:24 +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 5/5] arm64: introduce copy_mc_to_kernel() implementation 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-6-tongtiangen@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: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemk500005.china.huawei.com (7.202.194.90) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250213_185731_904673_3BC0987C X-CRM114-Status: GOOD ( 11.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 在 2025/2/13 1:18, Catalin Marinas 写道: > On Mon, Dec 09, 2024 at 10:42:57AM +0800, Tong Tiangen wrote: >> The copy_mc_to_kernel() helper is memory copy implementation that handles >> source exceptions. It can be used in memory copy scenarios that tolerate >> hardware memory errors(e.g: pmem_read/dax_copy_to_iter). >> >> Currently, only x86 and ppc support this helper, Add this for ARM64 as >> well, if ARCH_HAS_COPY_MC is defined, by implementing copy_mc_to_kernel() >> and memcpy_mc() functions. >> >> Because there is no caller-saved GPR is available for saving "bytes not >> copied" in memcpy(), the memcpy_mc() is referenced to the implementation >> of copy_from_user(). In addition, the fixup of MOPS insn is not considered >> at present. > > Same question as on the previous patch, can we not avoid the memcpy() > duplication if the only difference is entries in the exception table? > IIUC in patch 2 fixup_exception() even ignores the new type. The error > must come on the do_sea() path. As I said in commit message, it is not normalized with the memcpy() because of the lack of GPR. If there is no GPR shortage problem, we can extract the common code of memcpy_mc() and memcpy()，The unextracted code is using different exception table entries. Thanks, Tong. >