Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp1767709rdb; Sun, 4 Feb 2024 00:02:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IHM9jAXw2FI6nBVhgNVyZ1LQOdoFuYUjDdYDFDo7jWZKstxrgOGkB+LmUsanXd2gwt+2pKv X-Received: by 2002:a05:6808:1792:b0:3bf:d14d:d3d4 with SMTP id bg18-20020a056808179200b003bfd14dd3d4mr3250708oib.42.1707033740481; Sun, 04 Feb 2024 00:02:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707033740; cv=pass; d=google.com; s=arc-20160816; b=n/j+7VfgZEiXUaDZtvflVDEdN8ssGZm2VOM7KPwGuClXiEWHeBD/x+4sEZCE2B6fvg B0i2mBEQ1O2w34u2ZL5kcKrWwbG2zLuMUKADtYzQzT2s22V/duQR8jn7qmcpIRm0Ctxi NGiLi+tSwdlJDQMeU0xQaOe+oR+r74Qg2xjl5O/GkLAYtHXM0HaWw4RH1T54lVuWW7O3 34wSp6WhsBKs6j+tgQ0xbrnbid2ZyvbkWVj7H57m+rLrKkZ7uLCX5Gc7+ARTHzuu43c5 XsPXqHbwL7THllqZ6OzwmWza3R+88GvoJoI+Y98Z7XD1ZLcBGq0rKkP0oSB0K4ulTRSZ jiSA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=GIslQit7S7oN8dCTr9qPzRRrwsindq2gf8xiNd8bXcw=; fh=ez/STBGAiOJjWRFHNLk/Le5uhslVV+b6RejlaaXuKL8=; b=Mfz91vwrZE3HfG5oGDpR40pOePEHFT+Wd58ywmvsaiP9RyU4XFZ2fqjoxk5zcZT8xv riJaiXzEhGtUcZU3hd/KmAv9MGtvPeF3WocQUkt+vM0kvp0+K0422nKYqbotIP8rBQSW trq9DnKEe60M11cpK9rT1b5ekhb60C8UMLRN2IU2UcGZ+tz/IfjiaeOLybK1pRvqNdeS Zb3KbA+cY4yelokff1y4YhNDuYArkE8V7ItT70nOmr1JjWR8k/dDP9DIBhje6/C/O6vf Ad5rRltlUyK4Ls8vxWj1QGtwgrtBPIgTyvVfnGjCc+SP/tfyYp4PqF32Yz25+1I6/f9/ EsLg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=Zoi7DReU; arc=pass (i=1 spf=pass spfdomain=linux.alibaba.com dkim=pass dkdomain=linux.alibaba.com dmarc=pass fromdomain=linux.alibaba.com); spf=pass (google.com: domain of linux-kernel+bounces-51508-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-51508-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com X-Forwarded-Encrypted: i=1; AJvYcCX7BghdjqQIWrNE+pJgwDZQciir5d0djQlTT+InBc6EbhaX+QNmNy65Tvk/kUkkthspyAsunVujFwXJ0uX+3dfZfEiUbQGyy8ddSaquxw== Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id o17-20020a05622a045100b0042a87e2b8a6si5736060qtx.770.2024.02.04.00.02.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Feb 2024 00:02:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-51508-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=Zoi7DReU; arc=pass (i=1 spf=pass spfdomain=linux.alibaba.com dkim=pass dkdomain=linux.alibaba.com dmarc=pass fromdomain=linux.alibaba.com); spf=pass (google.com: domain of linux-kernel+bounces-51508-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-51508-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 279CA1C210B0 for ; Sun, 4 Feb 2024 08:02:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 53C7ACA47; Sun, 4 Feb 2024 08:02:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Zoi7DReU" Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0795BC133; Sun, 4 Feb 2024 08:02:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707033732; cv=none; b=h4RFK4yHsMCUUx7TySy+ilQi8tnTm4B3eUvZ+uBeMN+ZpB8LXsbgIUZjeNpnnMdS1W96M0/LQZFmzZPvyw4mKV4vX8GLloijQuK6iR0ctHyB3LRbs2cS5F/NeTF2bcOqi9cTu0kKgQEDxFYLd8Fc3d5c/BuYEzChmICFZ6XlsB8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707033732; c=relaxed/simple; bh=LUc8m/yU45sqH7o7HFActJOJuo71EMUn/FUJomqSufA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GdJP0D+7Ztq/Dtevh6k+WtVRzt0iL/+sVFL0qMNCzcbexzQkAB1AP4B3KjF1p6z06eLuOprz0qsNRMdjXPETMkUQ3P/YwRQYkzMLSgaA7YYPZDPv+1QMmvUaWw3ZXoIYmDfeD1ECi1LskJYWLHeyciAfzbxGQEKiEXFrkDlODTk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Zoi7DReU; arc=none smtp.client-ip=115.124.30.118 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ## 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