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 4DD79C48286 for ; Sun, 4 Feb 2024 08:02:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EA126B0072; Sun, 4 Feb 2024 03:02:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 79A1F6B0075; Sun, 4 Feb 2024 03:02:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 689A06B0078; Sun, 4 Feb 2024 03:02:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 55A196B0072 for ; Sun, 4 Feb 2024 03:02:07 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EE6671A07BE for ; Sun, 4 Feb 2024 08:02:06 +0000 (UTC) X-FDA: 81753378252.19.03F1B54 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf27.hostedemail.com (Postfix) with ESMTP id A89FF40005 for ; Sun, 4 Feb 2024 08:02:03 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Zoi7DReU; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf27.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707033725; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GIslQit7S7oN8dCTr9qPzRRrwsindq2gf8xiNd8bXcw=; b=a/JZYsczTlRDNYewvOSQOMH46k9emKpHn7X0pFnoyOy2DcF5MC8qvXf/lhSBfSHPm1/L8H I7ql3OeEjQ4Cge2YAp0yOdp7ghzPNdAxkOqEXMI78MSYJUdhNk/lxtIpZ+uduAeiCplUuZ cWJlEOuT/cIipEhAe3x9JX0h9bKmO4Y= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Zoi7DReU; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf27.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707033725; a=rsa-sha256; cv=none; b=yMOG+wMst0ZJqZ6vDiJGSrKF11VJfle+UDbjJFjfNZEvz+FC5D1x+NYCw8VmK7aa58qYfS JBXFKp6QDqM69WYk4sCgbNEazzGPfigyJU6BFuESvHkHFwXKoGyBIB6c9x3Cfb5fR5FVTn gmdTuFYu6nm0/FMzHRQsoNc4OJmXCKM= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1707033720; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=GIslQit7S7oN8dCTr9qPzRRrwsindq2gf8xiNd8bXcw=; b=Zoi7DReUFQyC5fZrdKbdmlnFO6YiwOwGOa0G0e13H9gmuRu3haoScT2eALniTo1n4mtR5sj0YbDC4iOoMUYXhMa5b4N5ol8cGif6CmmT2dpaC8XjST7XDd0qZsn2kX92BJfKKa4npy04uokDUAybEaQgnczvVtC6jr01VWKc3FI= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=33;SR=0;TI=SMTPD_---0W0003Bh_1707033704; Received: from localhost.localdomain(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0W0003Bh_1707033704) by smtp.aliyun-inc.com; Sun, 04 Feb 2024 16:01:58 +0800 From: Shuai Xue To: bp@alien8.de, rafael@kernel.org, wangkefeng.wang@huawei.com, tanxiaofei@huawei.com, mawupeng1@huawei.com, tony.luck@intel.com, linmiaohe@huawei.com, naoya.horiguchi@nec.com, james.morse@arm.com, gregkh@linuxfoundation.org, will@kernel.org, jarkko@kernel.org Cc: linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-edac@vger.kernel.org, x86@kernel.org, xueshuai@linux.alibaba.com, justin.he@arm.com, ardb@kernel.org, ying.huang@intel.com, ashish.kalra@amd.com, baolin.wang@linux.alibaba.com, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, lenb@kernel.org, hpa@zytor.com, robert.moore@intel.com, lvying6@huawei.com, xiexiuqi@huawei.com, zhuo.song@linux.alibaba.com Subject: [PATCH v11 0/3] ACPI: APEI: handle synchronous exceptions in task work to send correct SIGBUS si_code Date: Sun, 4 Feb 2024 16:01:41 +0800 Message-Id: <20240204080144.7977-1-xueshuai@linux.alibaba.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221027042445.60108-1-xueshuai@linux.alibaba.com> References: <20221027042445.60108-1-xueshuai@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A89FF40005 X-Stat-Signature: 7566e9oqh7hroxnzi7cofa5hsy3zbqa5 X-Rspam-User: X-HE-Tag: 1707033723-310099 X-HE-Meta: U2FsdGVkX182zK3V/TNmXPVBOuGNSqt0sdrO5CjBkkGziQAB11LHOJyvOCwkHqM+4/mAikEWyaKmbjjDio77MkijsYG41DmBn421+ZExKIhkqA2+ilyFgRaathxFcliyyx2qkxsrTWpHk34QEYXbdEC++BRLLrLgxGbVvCma8CXSD18628EwCXPJPLvSlHOnZIHDXN7wH4krZY6u1bns3+KV6PbYrmU+Dbh0caWnr1MlNEed4PCerDCovSmV9aPWe5XSJ+imxLtpnyRNoilSPISA5/pbkc94UiUtlRvLFN8rJ5ERQYZDzoYPtrXQYTlUdabnx8RoC8gKyj2MNPjUcdib+1gfAAGN/Rxno261ddATcd2z6MsWLN8RerCQqyLJNEmj6U/amBg6/gWvADM7LCzO7btbF5HXspf9QbodN+U7WeCG4lQvgRbOOfXlWTOJza/HwVnALqCgPTK161OgMMREAtgP+MkYCDrZhc2AcaLp2A3awSr37nQ11mZan6X2RUAxeLrO6sP7ZdaI6+TKqLUzg6Nak0RwS1KoskXWzTuh0BTixr7S8vJKzNZHSGEGHi9uZVClJN19eYWQx5wciSucK6nu6apGt6BoU/Isc6oYf/SOaabHHDOx+X+4fX6pzPddlSqkq6WGp6K2vFU5DycwJREt9mnR6EARnKjItHq8hQencL84Zavtbca765o/2ip/viFFFMeznYTJxRLPp8d9PzlwgQsmFEtbrrmNldubPMDm6kmiPvOpY/W6UeMfEbteiriBBptcOeNTBB/PgTZTVSh2b6eGQi4QiRuG9y6up6UjVcAZxy+BxPzsS86yElEH1AKlkmbo3sQ42rm0kPDjhv41NMGRzfpLLUVhelwdPaZdayaunFBIwo8B+JiGsy1Vx5Qj2wLxNzlSJNUc5ihM9qwgME5Zf5IEoQcR8XnK4kSmuGe4o9JMT6i0fF6Ukh9L7GYbP0TaTUkNV2r M0jgOrsy xJZti2ly7matSBuS30cRcX+14KioLnMLwCVySwNet6B4C4EsDveMb1svJ6s8TvPN8j79/ZFy7Lyw0SZsrVcwwBrZ8G7iu07qJRvQtQP+CiwSP8Z8HbFqe41aYsejxC1RSEbz92/ZN97VUiGn56Yfd5tmEUxYOk9kHvk2zQ//JAZrGK9LHTUKJl5ODATnopVJqhxw08eWqgh4nyAFqklSwK6WokD6HyhfHtfVdT7HMxjWXdKZJft0HvgCw2xplAz8WM9GnBoxEYQea5hpvAuXhYnrHHYXFxtO8nWs09Lt/3WFRh9L4jjJCLHlXSySVG+WfL148lgnKfzLygLhHaZVgsWSNsDhI95CtuyribqzwGl7f99pXVY7eTfplBUPoR7FULLdBmz/Ty0VXA0JtflzZ5enBjPM4Q2WiW+NL 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: ## Changes Log changes since v10: - rebase to v6.8-rc2 changes since v9: - split patch 2 to address exactly one issue in one patch (per Borislav) - rewrite commit log according to template (per Borislav) - pickup reviewed-by tag of patch 1 from James Morse - alloc and free twcb through gen_pool_{alloc, free) (Per James) - rewrite cover letter changes since v8: - remove the bug fix tag of patch 2 (per Jarkko Sakkinen) - remove the declaration of memory_failure_queue_kick (per Naoya Horiguchi) - rewrite the return value comments of memory_failure (per Naoya Horiguchi) changes since v7: - rebase to Linux v6.6-rc2 (no code changed) - rewritten the cover letter to explain the motivation of this patchset changes since v6: - add more explicty error message suggested by Xiaofei - pick up reviewed-by tag from Xiaofei - pick up internal reviewed-by tag from Baolin changes since v5 by addressing comments from Kefeng: - document return value of memory_failure() - drop redundant comments in call site of memory_failure() - make ghes_do_proc void and handle abnormal case within it - pick up reviewed-by tag from Kefeng Wang changes since v4 by addressing comments from Xiaofei: - do a force kill only for abnormal sync errors changes since v3 by addressing comments from Xiaofei: - do a force kill for abnormal memory failure error such as invalid PA, unexpected severity, OOM, etc - pcik up tested-by tag from Ma Wupeng changes since v2 by addressing comments from Naoya: - rename mce_task_work to sync_task_work - drop ACPI_HEST_NOTIFY_MCE case in is_hest_sync_notify() - add steps to reproduce this problem in cover letter changes since v1: - synchronous events by notify type - Link: https://lore.kernel.org/lkml/20221206153354.92394-3-xueshuai@linux.alibaba.com/ ## Cover Letter There are two major types of uncorrected recoverable (UCR) errors : - Synchronous error: The error is detected and raised at the point of the consumption in the execution flow, e.g. when a CPU tries to access a poisoned cache line. The CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64 and Machine Check Exception (MCE) on X86. OS requires to take action (for example, offline failure page/kill failure thread) to recover this uncorrectable error. - Asynchronous error: The error is detected out of processor execution context, e.g. when an error is detected by a background scrubber. Some data in the memory are corrupted. But the data have not been consumed. OS is optional to take action to recover this uncorrectable error. Since commit a70297d22132 ("ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events")', the flag MF_ACTION_REQUIRED could be used to determine whether a synchronous exception occurs on ARM64 platform. When a synchronous exception is detected, the kernel should terminate the current process which accessing the poisoned page. This is done by sending a SIGBUS signal with an error code BUS_MCEERR_AR, indicating an action-required machine check error on read. However, the memory failure recovery is incorrectly sending a SIGBUS with wrong error code BUS_MCEERR_AO for synchronous errors in early kill mode, even MF_ACTION_REQUIRED is set. The main problem is that synchronous errors are queued as a memory_failure() work, and are executed within a kernel thread context, not the user-space process that encountered the corrupted memory on ARM64 platform. As a result, when kill_proc() is called to terminate the process, it sends the incorrect SIGBUS error code because the context in which it operates is not the one where the error was triggered. To this end, fix the problem by: - Patch 1: performing a force kill if no memory_failure() work is queued for synchronous errors. - Patch 2: a minor comments improvement. - Patch 3: queue memory_failure() as a task_work so that it runs in the context of the process that is actually consuming the poisoned data, and it will send SIBBUS with si_code BUS_MCEERR_AR. Lv Ying and XiuQi from Huawei also proposed to address similar problem[2][4]. Acknowledge to discussion with them. ## Steps to Reproduce This Problem To reproduce this problem: # STEP1: enable early kill mode #sysctl -w vm.memory_failure_early_kill=1 vm.memory_failure_early_kill = 1 # STEP2: inject an UCE error and consume it to trigger a synchronous error #einj_mem_uc single 0: single vaddr = 0xffffb0d75400 paddr = 4092d55b400 injecting ... triggering ... signal 7 code 5 addr 0xffffb0d75000 page not present Test passed The si_code (code 5) from einj_mem_uc indicates that it is BUS_MCEERR_AO error and it is not fact. After this patch set: # STEP1: enable early kill mode #sysctl -w vm.memory_failure_early_kill=1 vm.memory_failure_early_kill = 1 # STEP2: inject an UCE error and consume it to trigger a synchronous error #einj_mem_uc single 0: single vaddr = 0xffffb0d75400 paddr = 4092d55b400 injecting ... triggering ... signal 7 code 4 addr 0xffffb0d75000 page not present Test passed The si_code (code 4) from einj_mem_uc indicates that it is BUS_MCEERR_AR error as we expected. [1] Add ARMv8 RAS virtualization support in QEMU https://patchew.org/QEMU/20200512030609.19593-1-gengdongjiu@huawei.com/ [2] https://lore.kernel.org/lkml/20221205115111.131568-3-lvying6@huawei.com/ [3] https://lkml.kernel.org/r/20220914064935.7851-1-xueshuai@linux.alibaba.com [4] https://lore.kernel.org/lkml/20221209095407.383211-1-lvying6@huawei.com/ Shuai Xue (3): ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered mm: memory-failure: move return value documentation to function declaration ACPI: APEI: handle synchronous exceptions in task work to send correct SIGBUS si_code arch/x86/kernel/cpu/mce/core.c | 9 +--- drivers/acpi/apei/ghes.c | 84 +++++++++++++++++++++------------- include/acpi/ghes.h | 3 -- mm/memory-failure.c | 22 +++------ 4 files changed, 59 insertions(+), 59 deletions(-) -- 2.39.3