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 899A2C021A0 for ; Fri, 14 Feb 2025 01:44:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08DC8280004; Thu, 13 Feb 2025 20:44:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 03DB1280003; Thu, 13 Feb 2025 20:44:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF936280004; Thu, 13 Feb 2025 20:44:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C2F46280003 for ; Thu, 13 Feb 2025 20:44:12 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 74D82141ACE for ; Fri, 14 Feb 2025 01:44:12 +0000 (UTC) X-FDA: 83116854744.17.2EE3C13 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf02.hostedemail.com (Postfix) with ESMTP id 96C9380006 for ; Fri, 14 Feb 2025 01:44:09 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.187 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=1739497450; 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=s6gybk0sDxsKPqVranOYHJNAYoMVjrehj07uCNXs5vM=; b=AIS4KBqowydKIBa2oam7i3CaVXvKj2XPj4tS1cfFTxkxtcWcbIPCso4ONfBFjPpwI5xNUF dyRQGuvfoD6rOrYcONRXwbtsofxHB6QESeBMmt2aq4N+tEiZ35RVKgYaP7YpYaQiXZYgcl jMSFdM8D8ii80QTlmU+Nmi+06FQG5yQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.187 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=1739497450; a=rsa-sha256; cv=none; b=UJSzzPQisb07ilW2a43z1MPi6Pp2r22aElK0JfLLCWMXb3jpx7CU1iOG1gqXCXtkPz3jc6 Iwzp+KowKRjP9bCEsBAdTMTvfC4F0vW3QIjw6LN5E19wznJAzoXU0o/C1LHKMbg/Hxzwr5 +ouP5T309YqicPahc+ky8sCJ/bPZK+A= Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4YvF8m1vkrz11PdJ; Fri, 14 Feb 2025 09:39:36 +0800 (CST) Received: from kwepemk500005.china.huawei.com (unknown [7.202.194.90]) by mail.maildlp.com (Postfix) with ESMTPS id 9BD7F1800EA; Fri, 14 Feb 2025 09:44:05 +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 09:44:03 +0800 Message-ID: Date: Fri, 14 Feb 2025 09:44:02 +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 2/5] arm64: add support for ARCH_HAS_COPY_MC 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-3-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-Rspam-User: X-Rspamd-Queue-Id: 96C9380006 X-Stat-Signature: 8tcsjc4axzsm9onodcbqgjn5ki67cuqs X-Rspamd-Server: rspam03 X-HE-Tag: 1739497449-544722 X-HE-Meta: U2FsdGVkX19/GQiII1EYdFXu5UjXbJObcEmpoAIRY9qV0nA5rioWoAp4Bpf8i3Tq8IbO5qS5KZASN41dIbo85nk/Mrl900kDdGtkhmPyik4tjvCXK08PAVJY2eekxlrf/87XOn1kQRsnoQfqOa+Y2gnv1bQfM7zGoxyhXCpzgCbE9bUswjbZk9GQit/LC1tH5GPAxjeVNeJ8KcuI/mqHuvzdHWyVhooxdr/YspZI2H3ps9JI+gUwzcyBlJYDwPn/ZPKF8H6UDAN5jaSTmrTov8mtbWYOrMkwBj2xRbqzvZ4UANnV08JRrRkTj+mDZUG0ZdU/1Heq2PMX7J/aJKb9y6IQqMUr1dWpvNA7XNvYLBrtiwE9nWHttOuDlZkQsfnuLcP12MPZvbhzXl8dbCtQqKBee6YU94Hd1WbPxN8OQkzTs+hB4JAvIoAXJ4hVt26+y7iu530ONhwBD5mxYrU39YJt6Zb3zqwExkaQ/upxSs7OGm9zeiSAT7Cz+sb8FJWSM3CCdq2zQGGUI7K0KfY4ILG68Dw+ujkemkfTEJnt3lL5oW3cFRLSAgbczILUlDNC8uN/c4Fr2v0QqP4GRnIVUKQgRf798XxA7s9UuWESbQaMxG5+Y4alxChkJxgpZxbMtm+FvOlF/wGlvT6KDN1j5zwouoLsFMG5toYMCN8SF8QoWjAEnRbWfOfzWy9N+Jf8YPmpKNPVDJ9d4Xqw2gSzq+8DNWJp0QJDa26MjuvfOj/QAzLLZxPGUfj+EGV4kCV4Q8cAEKxFaI+4dybNIMmuK0wVZLAhaRv94BrxZ4kalAbXCOf4KRZ4wM3fH9jt6WPX1LhwGpJ+cyJ+qWErjoW9k3qMn1L920U7lFEEYOUqu5DTecPCGrk7NmEfdnzvmCWoTSAKky7Mz5NFOU+bmCGjpKS4MYyQcy9eoAg8qHkt2/UNioTSOvBGsEyWyd2co1lLVAA9Phf6DipdUjMU0lL cOe9XZju 2ha0Uwt68DppwCwY0QJueQk/nW+mgatgEJ2+x2cDgshEDIhLaB2rkeC+pYWa6udr+6teDmVaLV441nhuhZNB1aKWwRuPPtLAnkmwSlwxT0l2mcFmnOHOVJ3kicaMopymGso+qwHhpkDTMOo15YJQRvEBAOVWpXyx8Yqt/Or8BXdLItWVWzB0QH2WyDH6O0wmZ5e2EvFJDE+SjMdSD6VlTBJwP2AGp7B925hUWz3HFfDt8S0QRialdRaWQ+9H2tge5DNU4SiHgr4NPSh2P6mqUr9+U5DhkSOHnGyr1 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/13 0:21, Catalin Marinas 写道: > (catching up with old threads) > > On Mon, Dec 09, 2024 at 10:42:54AM +0800, Tong Tiangen wrote: >> For the arm64 kernel, when it processes hardware memory errors for >> synchronize notifications(do_sea()), if the errors is consumed within the >> kernel, the current processing is panic. However, it is not optimal. >> >> Take copy_from/to_user for example, If ld* triggers a memory error, even in >> kernel mode, only the associated process is affected. Killing the user >> process and isolating the corrupt page is a better choice. > > I agree that killing the user process and isolating the page is a better > choice but I don't see how the latter happens after this patch. Which > page would be isolated? The SEA is triggered when the page with hardware error is read. After that, the page is isolated in memory_failure() (mf). The processing of mf is mentioned in the comments of do_sea(). /* * APEI claimed this as a firmware-first notification. * Some processing deferred to task_work before ret_to_user(). */ Some processing include mf. > >> Add new fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR to identify insn >> that can recover from memory errors triggered by access to kernel memory, >> and this fixup type is used in __arch_copy_to_user(), This make the regular >> copy_to_user() will handle kernel memory errors. > > Is the assumption that the error on accessing kernel memory is > transient? There's no way to isolate the kernel page and also no point > in isolating the destination page either. Yes, it's transient, the kernel page in mf can't be isolated, the transient access (ld) of this kernel page is currently expected to kill the user-mode process to avoid error spread. The SEA processes synchronization errors. Only hardware errors on the source page can be detected (Through synchronous ld insn) and processed. The destination page cannot be processed. >