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 B51B3C369A2 for ; Mon, 14 Apr 2025 15:02:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1563A280015; Mon, 14 Apr 2025 11:02:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 104D8280014; Mon, 14 Apr 2025 11:02:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F361A280015; Mon, 14 Apr 2025 11:02:29 -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 D521C280014 for ; Mon, 14 Apr 2025 11:02:29 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 50A7E16035B for ; Mon, 14 Apr 2025 15:02:31 +0000 (UTC) X-FDA: 83332965702.27.29A59E3 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) by imf19.hostedemail.com (Postfix) with ESMTP id 7D01A1A0004 for ; Mon, 14 Apr 2025 15:02:27 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=qWPsN03x; spf=pass (imf19.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.118 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=1744642948; 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=XP1wiJKn79M25SDS7QDbse457FmVwidLJBCVM8ARXV4=; b=rvGWBJii68MVocJXRe1iZwmMgueGhW5ImZUrSA3EuqpOkZYTAdp8LnfzDxRcWiyGzJmtsC zf5DRrmKK7b/wsyVA6DmQEbey6ReEGdU0wV7Sy07rYGVSzBpeOEYYGa7tojJyRR5GkWzzz yXda+z9A5TPtVzIU7RK9NlIsymP/y+g= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=qWPsN03x; spf=pass (imf19.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.118 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=1744642948; a=rsa-sha256; cv=none; b=Mhy7xkQl9u9zoqbzZw7m2m484Z+4BjW/dgcyfpFJlJB0Mj+NxdDN2M+0+iDgVzM3uG/Q9G PPD4IsZ+BoKyZ6R4oeSLnDHBmb0MoWSNYSfCdoU58fYlMiokZx9hLB5WL4dhflX76ibjKZ 8GTXu8WMIq6X0x3Vqk5mafDGKpAKwDM= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744642944; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=XP1wiJKn79M25SDS7QDbse457FmVwidLJBCVM8ARXV4=; b=qWPsN03xz9+pTwownWuaBgpyTH0pHxo1wiofftgmL4NUgVGKBx1rkK6Oc1UfaanaiLvQB5xPRY8PV3a9AquDZJ1I+R2PS3DQbJkxxcCjWz+N+mxOmRxoUl/shW77PYKWLyXuBt+ZRJvi9SGe0HcE0BRz4lOCI87ZOp2NORAKphE= Received: from 30.246.161.79(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0WWsd0xB_1744642940 cluster:ay36) by smtp.aliyun-inc.com; Mon, 14 Apr 2025 23:02:22 +0800 Message-ID: <709ee8d2-8969-424c-b32b-101c6a8220fb@linux.alibaba.com> Date: Mon, 14 Apr 2025 23:02:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v18 1/2] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered To: Hanjun Guo , catalin.marinas@arm.com, sudeep.holla@arm.com, lpieralisi@kernel.org, linux-acpi@vger.kernel.org, yazen.ghannam@amd.com, mark.rutland@arm.com, mingo@redhat.com, robin.murphy@arm.com, Jonathan.Cameron@Huawei.com, bp@alien8.de, rafael@kernel.org, linux-arm-kernel@lists.infradead.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, jarkko@kernel.org Cc: 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@linux.alibaba.com, ashish.kalra@amd.com, baolin.wang@linux.alibaba.com, tglx@linutronix.de, 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: <20250404112050.42040-1-xueshuai@linux.alibaba.com> <20250404112050.42040-2-xueshuai@linux.alibaba.com> <0c0bc332-0323-4e43-a96b-dd5f5957ecc9@huawei.com> From: Shuai Xue In-Reply-To: <0c0bc332-0323-4e43-a96b-dd5f5957ecc9@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 7D01A1A0004 X-Stat-Signature: e7e7ca5b3g1opbqwzjf8yzje1puugjx9 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1744642947-186432 X-HE-Meta: U2FsdGVkX19+tNsM9IExHfx5C7X2VMKw2nL+fmjjhJY68N1H0x3UhYiaUAFFwVHnNXV78PIGWgTkkQVstbOuiMjR+78Tz5LEo4jcHOVW9xDoCZ+Lf+JzBZUG+loRTP9JU4EUsHojJuKAZVTfczEgS7D7+K3WbSJHLhln6OisARcQAlJezy1nH7HjoWhEaGl98lvDxdKSeunL89WE3wu/navsBdFJbO6j99T++pz0rVHnedI1k+kNaHRz3bce2rBxHnu30Cobfv04KGlXF476Fd0lpdNElhTkOk1lfvRPqVrGzNc+8KnV3Tdxk57Nh7HyNy88hfxD74guS5eDqsCc0Bpsyh2IGcd0p7PnfXKJfsVC4kUz+ATN5Ki8p2g96XsZoe9L6Z4Daii5n10JfVsNiq/afm3qV732OpksjRTIk/RFZaSUX8wXPWM+usL5eRgHleFlExRzPn+Rv/LBWqUaH6uXpPfVdrYup1y5cLz+9E9D0X8tXhL/R0VogR2Muh5d/jlAAIplPwnh01QUzutcpfztBTolRikYk/BH9aiCuvPqTg/G0AE8/3G2I679YNgM8lzhab4CRwnYVbnyB33kCj9nTCJwwcYaZe0jDZairDeOdX5TEvIRWT3vlvcUfv5TdUAwSlU8JShyflSwrHn3E2DxPEzzO3GpRITsIWdDiM0uaLT5Zw5Mtl8Zt6WI7lzdIjzImCektlk7+bxxuB68dYVN7PWiEGQP0X4ymTOO9LZqhq5EcB8hkXV/8OUdcwguyWIS0pEO6kloKM1OhqCljUjmwDLlMTWjGmyGnq6DpukpfAcrm8AgdskWvp/SuY0CfqXMK/D7lmCmG/fnzkTKmHE0EYBqhFcUKbK46fXjq9aB5omGEtupbAyxl2cO9dle9N7u1FAULghe5GTJT7L/7fy6wUCA5jqzLWcckXB9jTm9SEzgsZ76ySgbh7z42FcMl4vUHTkCBAd8Z3dCK4C BrT55XGQ EGxe/COG2kGjRiPvpIHpwFzzLBEUbE2Ta8JHQrCK/U1kTs1tqK3sMpHeZAlS9GnL1sxGuxK8GAcW9EjE5OrQGP2sVr2ErBVY4o0vk9zC6IZBlRq9ASLXNDqyG12uicQ++j3/Zl+eOmRKwhjNlYv6Y34vXFDBrf+npKKDMAMfPCdVdvDe20iiibZDdmVV+LO/zHRg3PcwuDHm9ZGydnHjYYTa874SNYwJ8e0KBxf9Y6Yz0hx5XgE0cuU7u1ykQ6PAd2iddo+Ri6YC9Y/3WJ1syGL3PR5rc1Xl5JegLmJdOTwU5007Dxnbkqn7P7o5RD/nLRzIO8DOht5LZGTDopfnJI7fpadRbtBmNO3/CHImlji5aj4vampRfMAZRXyLPukffMuZFQO5lxNCIjgs= 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/4/14 22:37, Hanjun Guo 写道: > On 2025/4/4 19:20, 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 >> Reviewed-by: Jarkko Sakkinen >> Reviewed-by: Jonathan Cameron >> Reviewed-by: Yazen Ghannam >> Reviewed-by: Jane Chu >> --- >>   drivers/acpi/apei/ghes.c | 11 +++++++++++ >>   1 file changed, 11 insertions(+) >> >> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c >> index b72772494655..50e4d924aa8b 100644 >> --- a/drivers/acpi/apei/ghes.c >> +++ b/drivers/acpi/apei/ghes.c >> @@ -799,6 +799,17 @@ 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) { >> +        dev_err(ghes->dev, >> +            HW_ERR GHES_PFX "%s:%d: synchronous unrecoverable error (SIGBUS)\n", >> +            current->comm, task_pid_nr(current)); >> +        force_sig(SIGBUS); >> +    } > > I think it's reasonable to send a force kill to the task when the > synchronous memory error is not recovered. > > But I hope this code will not trigger some legacy firmware issues, > let's be careful for this, so can we just introduce arch specific > callbacks for this? Sorry, can you give more details? I am not sure I got your point. For x86, Tony confirmed that ghes will not dispatch x86 synchronous errors (a.k.a machine check exception), in previous vesion. Sync is only used in arm64 platform, see is_hest_sync_notify(). > > Thanks > Hanjun Thanks. Shuai