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 6EA99CE7AA5 for ; Fri, 6 Sep 2024 01:53:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DDF56B0082; Thu, 5 Sep 2024 21:53:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 88E416B0085; Thu, 5 Sep 2024 21:53:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 755A76B0088; Thu, 5 Sep 2024 21:53:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 576EE6B0082 for ; Thu, 5 Sep 2024 21:53:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E916640C54 for ; Fri, 6 Sep 2024 01:53:44 +0000 (UTC) X-FDA: 82532641968.10.3E8FCD3 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) by imf19.hostedemail.com (Postfix) with ESMTP id DE93E1A0007 for ; Fri, 6 Sep 2024 01:53:41 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=ITtirQEP; spf=pass (imf19.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.99 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=1725587573; a=rsa-sha256; cv=none; b=JjBGR3/89cn3gDiMj7N+G4lMIQEkFaKWyW2YDMpuEWKnHzTteEvEa8h3WJu6LKcJaEJT4Z x0a84T3zXxvX/YPLeiuc7kXiuA2vT2GzUXQKyHn3xWzrBbbahv6mDJQwRAs9COfC8um6R7 kSdJZQwwYku8dB6qTa+ycxh1h09w3q8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=ITtirQEP; spf=pass (imf19.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.99 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=1725587573; 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=yXCCgOuWDZJBwrrZhsFP69ynA9Ps5ml3WXCsMeJVNTQ=; b=z7y1h45yalI5ZbA82xR1nxib4tm+qR1jPxskoW9ZWsgup3Lj8us8Xnx5Z00IzzqWj5vZdr vtz8qUT8/Xvl32AprTfb1Co3z0G9tKLCukSxSMSgrFS3Xh+Seofsc/SB3lF5DKHrYccEhx kCo6a0XxVCShIoGvuprWe8Cop0zqXvg= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1725587615; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=yXCCgOuWDZJBwrrZhsFP69ynA9Ps5ml3WXCsMeJVNTQ=; b=ITtirQEPxGpi9kdKM+EdwFUZccl3xC2+TtkJSry5nuuL9eQWkVmhdX+h8aMjIKLt/GXC92uLdY73yTr5jfYnHamKgkq6k3i0nSZjmyi/H+zjcdafJ4grlNyE/CwGStFMZ+dOANiVMiwCRbPYsIzNNqNcO4q8bsfWsQFlJrP5i1E= Received: from 30.246.162.144(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0WENXsHu_1725587611) by smtp.aliyun-inc.com; Fri, 06 Sep 2024 09:53:33 +0800 Message-ID: <34d5d58b-7fc2-4f93-9d3b-3051ec5e6a23@linux.alibaba.com> Date: Fri, 6 Sep 2024 09:53:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/3] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered To: Jarkko Sakkinen , 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, tongtiangen@huawei.com, gregkh@linuxfoundation.org, will@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, 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 References: <20221027042445.60108-1-xueshuai@linux.alibaba.com> <20240902030034.67152-2-xueshuai@linux.alibaba.com> From: Shuai Xue In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: z1a97dfdowq14ot6chmsyenpeni6fnmk X-Rspamd-Queue-Id: DE93E1A0007 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725587621-105821 X-HE-Meta: U2FsdGVkX19qUvRZwby9PJw9nsAQu88Ywbq1YFWmDWrrUoe+Zqgy6Fqo676slMtjbrEovlva3DuRZVRDj4LNBcknc80EQ2HC7OyxVwT5lNTKU9taK/XLSxrzg3WNK3XYki+Q7JaJk7Rh5CAJGViGK+NPnPbc2RcdSRIGgKvZrP8J0w254jbuU2zWPkpTlKw4WN2+rtgbSCE+36Qti51vEL9ipYD1WXQvPEXQq6Wna151VZEhYIWD2N/QLFJi/p4JLsROOlBXNlECBombLPtvBXex+p7SVd6CIsotd+X/VN+3jCk1QJNpf5aQAURBn9KqHYRS4CQIbM4djhtyfZoh85nVUG4EfHNYVI1crD4GH6Sd7ox85A2VpBrn8mn+i3UxnAe+niRjcwSa8aH6O+w7+7qhqk2lGoie2WNxScBrhT+s6rXju6MaX/D7ucFFjz5+OdE25X4fqueTjBYkUsoOkViBfGUkEWVAbIE3vUNfjmDD7YcWTBYMmFzZAXra3B3ho+p9KnblUAG3QJXARM5IezIFsp/OqtiLIZtvhul9mRoIePlcs9UHPOgE6hn32zTKsY9PIf/uuJ/U2QY9/qi6wBeQhDFks8uum5sUkuJdYUzzjxE5DolgPpd+6RVL27wRti74/TIJeb9yJ2YXqQDAQeOEB0aVogGKDGE3xIrRPICa4csfMWQ7s8CV0anrs9pZxvAVVJZTe3KA26Dq3z35T4w+4e0wtt0lS6Cb+48bvwAbTI0Qmi2hpokf585paB7hQpSBa2Tg/UrsYLFBURa9r11gb1rg9MARLNduw32NTQKwnFnYV9/e9G1XxpbrCLZFaUd/aYHab7ACBX1XGO61Fz9PAtngQ8ncZlLOAuOOAitNonTysTOgu14Z4Y0C5ps/orVCNgZM7rtcE9bhZ8/Mdce4wnMNFlnUnewXg/G1oI6aY7fd0kvPAHvaD2miJaQoZg/vKdxTZBkASZNhq0v evLhT1+s hV+K9Cx4jA8xxZwX+tK9Is6PYJfg/WlbzEikSd0ue+xanxeUjMNsvW+pIUnXr/wtvWyiP3kUv8JBOastEO4wJd2zioYYg4ySc5nKS02/a3c4Oq+t91fPiGR4E6Jz9OyYbMHa7HHs9313IqtG5N5I9TJiUUabUIKNLicIwzHlnONJr5apv7f/wde24nXcT3y1UUMkeVk0xEo+68qphXADZUDqW/zv9UFZsqJQUt+kJlGAECl7qVgcfsH7oNGiwTzxVYaC+U21PiPvS4xqe3d9yPI4p/xqVhiFZBcI6+Zkn6pQYvySgA85Sjw9DXVNi23gYvAeL8uO8kSf2oA0= 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: 在 2024/9/5 22:17, Jarkko Sakkinen 写道: > On Thu Sep 5, 2024 at 5:14 PM EEST, Jarkko Sakkinen wrote: >> On Thu Sep 5, 2024 at 6:04 AM EEST, Shuai Xue wrote: >>> >>> >>> 在 2024/9/4 00:09, Jarkko Sakkinen 写道: >>>> On Mon Sep 2, 2024 at 6:00 AM EEST, 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 unless all bellow >>>>> preconditions check passed: >>>>> >>>>> - `if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))` in ghes_handle_memory_failure() >>>>> - `if (flags == -1)` in ghes_handle_memory_failure() >>>>> - `if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE))` in ghes_do_memory_failure() >>>>> - `if (!pfn_valid(pfn) && !arch_is_platform_page(physical_addr)) ` in ghes_do_memory_failure() >>>>> >>>>> 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. >>>>> >>>>> Suggested-by: Xiaofei Tan >>>>> Signed-off-by: Shuai Xue >>>>> >>>>> --- >>>>> drivers/acpi/apei/ghes.c | 10 ++++++++++ >>>>> 1 file changed, 10 insertions(+) >>>>> >>>>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c >>>>> index 623cc0cb4a65..b0b20ee533d9 100644 >>>>> --- a/drivers/acpi/apei/ghes.c >>>>> +++ b/drivers/acpi/apei/ghes.c >>>>> @@ -801,6 +801,16 @@ 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 %s:%d due to hardware memory corruption\n", >>>>> + current->comm, task_pid_nr(current)); >>>> >>>> Hmm... doest this need "hardware" or would "memory corruption" be >>>> enough? >>>> >>>> Also, does this need to say that it is sending SIGBUS when the signal >>>> itself tells that already? >>>> >>>> I.e. could "%s:%d has memory corruption" be enough information? >>> >>> Hi, Jarkko, >>> >>> Thank you for your suggestion. Maybe it could. >>> >>> There are some similar error info which use "hardware memory error", e.g. >> >> By tweaking my original suggestion just a bit: >> >> "%s:%d: hardware memory corruption" >> >> Can't get clearer than that, right? > > And obvious reason that shorter and more consistent klog message is easy > to spot and grep. It is simply less convoluted. > > If you want also SIGBUS, I'd just put it as "%s:%d: hardware memory > corruption (SIGBUS)" > > BR, Jarkko Hi, Jarkko, I will change it to "%s:%d: hardware memory corruption (SIGBUS)". Thank you for valuable suggestion. Best Regards, Shuai