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 00428C48BEB for ; Thu, 22 Feb 2024 02:07:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72AF16B0072; Wed, 21 Feb 2024 21:07:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DB356B0074; Wed, 21 Feb 2024 21:07:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C95D6B0075; Wed, 21 Feb 2024 21:07:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4BF716B0072 for ; Wed, 21 Feb 2024 21:07:32 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1564580C74 for ; Thu, 22 Feb 2024 02:07:32 +0000 (UTC) X-FDA: 81817803144.28.FF4CCBC Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) by imf28.hostedemail.com (Postfix) with ESMTP id 85AF7C000C for ; Thu, 22 Feb 2024 02:07:28 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=A8ueD57L; spf=pass (imf28.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.111 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708567650; a=rsa-sha256; cv=none; b=LcTd7CcwuT/NUMNI2f+5rPAG9EnIPerqmFa9L5jH2++gYWaQA5MIU5X35nbo/0lguxm6u5 H1EI57NA5ZcO7lsggKEypWMLDeA2N3Dafs3sKDYWEDgN3eBxGtUPXRE82RwRUUMzM3OKng aGuo1d48RrAbLzB5NP0WbHfw6j4KT9Y= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=A8ueD57L; spf=pass (imf28.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.111 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708567650; 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:dkim-signature; bh=lDGwJr9TuPvJsHHw5w4m96qLqRHU5UZ2FIU9NMbibkY=; b=0OKNjfXaqpLM3ElxPgUu4MClwL+veFL6wwngOzhkqZ7SVE0TywdLmMiOrri5XSZNNMmI3c ZgrqMkQOBJfydcB5IqTkLAiM1GWBJ+3BNAUIe5xf8mbJ8/F1qT9wG2oSZwpcl+VkCjSIP4 UeaSsS6KfMVfc98CCh3H6PgZe3kaYsg= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1708567643; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=lDGwJr9TuPvJsHHw5w4m96qLqRHU5UZ2FIU9NMbibkY=; b=A8ueD57LHf7MbajhH79rIyYgUfbJo8opaQywVBP+DenqGrQtYkHvZiMjDE/j+fyGliFirC+iqLA122Qj2xNd38Tc1VMHSEl7WkdPSbz2ATtiJ30WRIurPSRoqLEfPkQWN/8w64DfD+N4IaIS31uLmAuhGfGJmwm+GccfamxO0NY= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045192;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=35;SR=0;TI=SMTPD_---0W1.N3yS_1708567639; Received: from 30.240.113.243(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0W1.N3yS_1708567639) by smtp.aliyun-inc.com; Thu, 22 Feb 2024 10:07:22 +0800 Message-ID: Date: Thu, 22 Feb 2024 10:07:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 1/3] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered To: Borislav Petkov , Ira Weiny , "Luck, Tony" , "james.morse@arm.com" Cc: rafael@kernel.org, wangkefeng.wang@huawei.com, tanxiaofei@huawei.com, mawupeng1@huawei.com, tony.luck@intel.com, linmiaohe@huawei.com, naoya.horiguchi@nec.com, gregkh@linuxfoundation.org, will@kernel.org, jarkko@kernel.org, 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, 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, Jonathan Cameron , Dan Williams References: <20221027042445.60108-1-xueshuai@linux.alibaba.com> <20240204080144.7977-2-xueshuai@linux.alibaba.com> <20240219092528.GTZdMeiDWIDz613VeT@fat_crate.local> Content-Language: en-US From: Shuai Xue In-Reply-To: <20240219092528.GTZdMeiDWIDz613VeT@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 85AF7C000C X-Stat-Signature: bm4wjaxuk4nggubb3tz3ub38kyjt5wbp X-Rspam-User: X-HE-Tag: 1708567648-931800 X-HE-Meta: U2FsdGVkX1+fnz2I+6M1BqqfgcGRgY9bDtDBSqsFGMaIhK6bQQwbykG02v+BmTcUwgAaPOEgaOC6Q9Xd8eCvCLMadkKqJichH3kbBNuuTewb8bX+JUBU9B9T5GMdVXzz2iEGiW8f0thMScAqqwd4VUbI351GDEKvxaMoqfcMXbnnexIQfbGHKMx4zNmNw7dlgau73Z7HOGoVPh2wu7OZh2Kcvi+gNscyigu+Cy0vviPaZFr1+mflcO9weP+YVrj4yxGXeiw9fYFVfMgy/+EkS7fXaZFBdUudmeYLVHpgKIQ9UFLHnnFaq/b9OVgLKSm+6oMB+MkW06b59EITKfNfFZ3HaZB/O0PEhp9M4uRY0J5Yw/iZawF4DhG0702Gz1Ga7yX+ztwZ9WOd8OphlntGtO7qjXJTTBW1/K6J5T0RkO0TJnvNxhzrcacpKaTI0FLHZ7ppSLU3hZ7hctEDyrFsXhfDt+skOrX8apEq/dHh93dh8Kb282iEIXdc5P76OvPxHXme5m49g5EXKOb8AXmaCr0uBcc1R57WdVoDUiCtGvrEFKM89plI+CHpeldtMQT5ocEnR48ggFi8UzocY64uW7y1+JnXm7N8ZfVabQ0Bh8kmhhp99HeVKCf0C4QkWLmPIvy6T/paC3cHi+BSaDK8j3VwWtl7dGgIRN0PDdzSroVNbqF5bFZ9/lhwUkRPmfGky3GHot1xezVHtvXw8cAVCTf8nrW8B8aGke94AafVmJk3UpH+16YCerBwevqxi3do3oLyrfmMXB92oBSuSdxYck9ndx5tybULEYVBhr7bxw7wLGneEKfzM6swtlyxzGyb/ZtQ29/8Ej/x0xNqubnpipMUy/GoLbAYz5Gd8DCyISjC7AyjgOO8Yzt6KYDpPEmI5wIx4r/9yYx2ooI4QhOPU+tXnNob3zoYkRGH7ZOkE4dazqYrW1JnxS7yOAX+XHTyH9N95u0KjnfhaHVHyWa DM9DPI4v EPufYAZmL6c+mcCRs9Zg1hlA6JTNTZhyjOyQ+0E9gk7poxB9Ngn3IMDg6MtuHBZljH0xon996PiFJ4wfDQPpoKOVN+XQlUapuRqlBMa5BtHZIEDBZ285ieUuh2XHs5BUvBo7m3bpzBpjjg4VisUYPkRVditCg2JiiB3pu/69l1/1xuIw3dswV97H7kKgnL/XowkAtwDMjgYRCyn1+VxldV/1arRPbUX3Im12nwCIclKzYzJNoiGiUEN31J/YepH9/NUVbf8i7ROVHVjWIQMw61vbLyg== 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: On 2024/2/19 17:25, Borislav Petkov wrote: > On Sun, Feb 04, 2024 at 04:01:42PM +0800, Shuai Xue wrote: >> Synchronous error was detected as a result of user-space process accessing >> a 2-bit uncorrected error. The CPU will take a synchronous error exception >> such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a >> memory_failure() work which poisons the related page, unmaps the page, and >> then sends a SIGBUS to the process, so that a system wide panic can be >> avoided. >> >> However, no memory_failure() work will be queued when abnormal synchronous >> errors occur. These errors can include situations such as invalid PA, >> unexpected severity, no memory failure config support, invalid GUID >> section, etc. In such case, the user-space process will trigger SEA again. >> This loop can potentially exceed the platform firmware threshold or even >> trigger a kernel hard lockup, leading to a system reboot. >> >> Fix it by performing a force kill if no memory_failure() work is queued >> for synchronous errors. >> >> Signed-off-by: Shuai Xue >> --- >> drivers/acpi/apei/ghes.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c >> index 7b7c605166e0..0892550732d4 100644 >> --- a/drivers/acpi/apei/ghes.c >> +++ b/drivers/acpi/apei/ghes.c >> @@ -806,6 +806,15 @@ static bool ghes_do_proc(struct ghes *ghes, >> } >> } >> >> + /* >> + * If no memory failure work is queued for abnormal synchronous >> + * errors, do a force kill. >> + */ >> + if (sync && !queued) { >> + pr_err("Sending SIGBUS to current task due to memory error not recovered"); >> + force_sig(SIGBUS); >> + } > > Except that there are a bunch of CXL GUIDs being handled there too and > this will sigbus those processes now automatically. Before the CXL GUIDs added, @Tony confirmed that the HEST notifications are always asynchronous on x86 platform, so only Synchronous External Abort (SEA) on ARM is delivered as a synchronous notification. Will the CXL component trigger synchronous events for which we need to terminate the current process by sending sigbus to process? > > Lemme add the whole bunch from > > 671a794c33c6 ("acpi/ghes: Process CXL Component Events") > > for comment to Cc. > Thank you. Best Regards, Shuai