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 58527E784AF for ; Sat, 7 Oct 2023 02:02:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA74A80022; Fri, 6 Oct 2023 22:02:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B570E80008; Fri, 6 Oct 2023 22:02:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A46E880022; Fri, 6 Oct 2023 22:02:00 -0400 (EDT) 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 95C9080008 for ; Fri, 6 Oct 2023 22:02:00 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 69343A02CE for ; Sat, 7 Oct 2023 02:02:00 +0000 (UTC) X-FDA: 81317014800.18.855F8CA Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 33E582001E for ; Sat, 7 Oct 2023 02:01:54 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696644118; 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; bh=3fZjFmTLkRBscuP536gGNcC/XACaUw/W26cI93o95ZQ=; b=VCW82AIka05yDNkDgMNH7MR/WBGaMCy/A6sNtrds/qBCwGAGFfrcmgxotceaDCyFJJHEP0 BIafmY+ryhU9SAY3OiulCLKMrLi9dlGJCDnWsMpo8cXt4hW1SgVeWJkz63tAkSXsGFsghv eqoCYwgnT3nUaXlWH2eNXFmgS8alTiE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696644118; a=rsa-sha256; cv=none; b=VO7BiJZloo3vWT1sV8TKtQeN+ZVn0u4c4kuDw9sSPEhZojtkuTpNNZaSRDyrHLgtQLO6ZU 9Htl77dQaVcJe2V3f+VQ1FILSH1gReaLqcoT7l3XQZ8DSWYV0bN5D5ztB7/vaYbdTyAoPP XGEZ8oVNCqD30R6wSTrNo5fOBFMwSMo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=35;SR=0;TI=SMTPD_---0VtTbrvR_1696644107; Received: from 30.240.114.194(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0VtTbrvR_1696644107) by smtp.aliyun-inc.com; Sat, 07 Oct 2023 10:01:50 +0800 Message-ID: <645ee424-316b-c093-6113-9abdfb42dab5@linux.alibaba.com> Date: Sat, 7 Oct 2023 10:01:46 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RESEND PATCH v8 2/2] ACPI: APEI: handle synchronous exceptions in task work To: Naoya Horiguchi 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, james.morse@arm.com, gregkh@linuxfoundation.org, will@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, acpica-devel@lists.linuxfoundation.org, stable@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, bp@alien8.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, jarkko@kernel.org, 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> <20230919022127.69732-3-xueshuai@linux.alibaba.com> <20231003082858.GA750796@ik1-406-35019.vs.sakura.ne.jp> Content-Language: en-US From: Shuai Xue In-Reply-To: <20231003082858.GA750796@ik1-406-35019.vs.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 33E582001E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 9z4gx5q5hq3z9xtomnuad7bds9gdypgm X-HE-Tag: 1696644114-374508 X-HE-Meta: U2FsdGVkX18oSZnmpT+VPqieZvExzlx94u8+erUa8PERpDAU6WVYv3TaTZar5Ffie8umxuoSSi+7YaV6iI1WxgnNdmAGv2txzhVWUlCLwaXxVAbwwZlapDUFw9K4T/nimdfjtf4gGx3GESdAhPKTrMCFZmLflbjrI0QMrhcaGGMRmM3gfMtK5mtx/foUEYzmNq1irGeoUq+y9+BDoVzMOKJonFN2z7yFfkp4bMSvJFAxqv/3V+MuZP+S1hvgmBDArbEbNdr73vsKlgMVgtntuHzjASxmai+zDIPhRKunakqzvSC3FMSNZUS4/kIiwu6fOfUAOdyO4bfcOhEjFi/+TzzU1wa7i2hj6sucXiDLYG0yS2G5xECmhWxiBFhekmN1SLeX0cPxdp1jcIp7Zau0LMdW8bXsDFYXSOod7tEFTy5lDj19GxwgoOOXmfKFvPVjs6YEi5OR17FHho1uPkVrJDRlix1BnA49f+vTO1EkH8dS/5xvt9rsXi0gMNfO+khhkwqhkC7HNC6wSsuFK3x//Ja22u5F8I8IntEccOr8jXtuBR7Q8WhunevKFPeXuUiCX0Ly0rj5epDvhSDir5h5iLtDnb/znDxR7hxEworqLE+qSNUUIRCpOTs3JrFsv2V1o+YySGKeMiUD/55+0aSCtwQfDGjoRWh1vK0pnLhnIaoGlXopWxWW51V3FJyhigRRmvvMU7OdAVl8kkxA98qavrM5zCNZai6MHeiTKMBP5YY1gDv9XZmfdppWsGGhnjGYopeok2wmwOmMkj/LQodugV5hUCh8r7Elo2L8OWF7Utk1LugJdAUeMBs5XVyjY91PQnp1jMt5KCNL+18jQEWUk8KqSJFXCdM0nQDPsHaHRRMqlDJ4bzWKP1bzLNmChnZF/HK2Z0XUeTKi7S6p7qzNcQGDa6flhYu4BIDbR+DTqXBL7ZKIF0vOF9VDUmr2Bzt2PStL0zJeD8X9Jvotj1Y fQpA4Ipu aMkLrhAR19tST/rp/dFFuKNm9nyj2N2OlbvP1b4qBz4Z8doP5UN5jh8lww+CUAX9Gy2Tamu2NPQEGQRt513C0UNPBkKeCvIPMdrJuk/OnkAb+sRQwbpMosvbASQ== 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: On 2023/10/3 16:28, Naoya Horiguchi wrote: > On Tue, Sep 19, 2023 at 10:21:27AM +0800, Shuai Xue wrote: >> Hardware errors could be signaled by synchronous interrupt, e.g. when an >> error is detected by a background scrubber, or signaled by synchronous >> exception, e.g. when an uncorrected error is consumed. Both synchronous and >> asynchronous error are queued and handled by a dedicated kthread in >> workqueue. >> >> commit 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for >> synchronous errors") keep track of whether memory_failure() work was >> queued, and make task_work pending to flush out the workqueue so that the >> work for synchronous error is processed before returning to user-space. >> The trick ensures that the corrupted page is unmapped and poisoned. And >> after returning to user-space, the task starts at current instruction which >> triggering a page fault in which kernel will send SIGBUS to current process >> due to VM_FAULT_HWPOISON. >> >> However, the memory failure recovery for hwpoison-aware mechanisms does not >> work as expected. For example, hwpoison-aware user-space processes like >> QEMU register their customized SIGBUS handler and enable early kill mode by >> seting PF_MCE_EARLY at initialization. Then the kernel will directy notify >> the process by sending a SIGBUS signal in memory failure with wrong >> si_code: the actual user-space process accessing the corrupt memory >> location, but its memory failure work is handled in a kthread context, so >> it will send SIGBUS with BUS_MCEERR_AO si_code to the actual user-space >> process instead of BUS_MCEERR_AR in kill_proc(). >> >> To this end, separate synchronous and asynchronous error handling into >> different paths like X86 platform does: >> >> - valid synchronous errors: queue a task_work to synchronously send SIGBUS >> before ret_to_user. >> - valid asynchronous errors: queue a work into workqueue to asynchronously >> handle memory failure. >> - abnormal branches such as invalid PA, unexpected severity, no memory >> failure config support, invalid GUID section, OOM, etc. >> >> Then for valid synchronous errors, the current context in memory failure is >> exactly belongs to the task consuming poison data and it will send SIBBUS >> with proper si_code. >> >> Fixes: 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors") >> Signed-off-by: Shuai Xue >> Tested-by: Ma Wupeng >> Reviewed-by: Kefeng Wang >> Reviewed-by: Xiaofei Tan >> Reviewed-by: Baolin Wang >> --- >> arch/x86/kernel/cpu/mce/core.c | 9 +--- >> drivers/acpi/apei/ghes.c | 84 +++++++++++++++++++++------------- >> include/acpi/ghes.h | 3 -- >> mm/memory-failure.c | 17 ++----- >> 4 files changed, 56 insertions(+), 57 deletions(-) >> > ... > >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >> index 4d6e43c88489..80e1ea1cc56d 100644 >> --- a/mm/memory-failure.c >> +++ b/mm/memory-failure.c >> @@ -2163,7 +2163,9 @@ static int memory_failure_dev_pagemap(unsigned long pfn, int flags, >> * >> * Return: 0 for successfully handled the memory error, >> * -EOPNOTSUPP for hwpoison_filter() filtered the error event, >> - * < 0(except -EOPNOTSUPP) on failure. >> + * -EHWPOISON for already sent SIGBUS to the current process with >> + * the proper error info, > > The meaning of this comment is understood, but the sentence seems to be > a little too long. Could you sort this out with bullet points (like below)? > > * Return values: > * 0 - success > * -EOPNOTSUPP - hwpoison_filter() filtered the error event. > * -EHWPOISON - sent SIGBUS to the current process with the proper > * error info by kill_accessing_process(). > * other negative values - failure > Of course, will do it. >> + * other negative error code on failure. >> */ >> int memory_failure(unsigned long pfn, int flags) >> { >> @@ -2445,19 +2447,6 @@ static void memory_failure_work_func(struct work_struct *work) >> } >> } >> >> -/* >> - * Process memory_failure work queued on the specified CPU. >> - * Used to avoid return-to-userspace racing with the memory_failure workqueue. >> - */ >> -void memory_failure_queue_kick(int cpu) >> -{ >> - struct memory_failure_cpu *mf_cpu; >> - >> - mf_cpu = &per_cpu(memory_failure_cpu, cpu); >> - cancel_work_sync(&mf_cpu->work); >> - memory_failure_work_func(&mf_cpu->work); >> -} >> - > > The declaration of memory_failure_queue_kick() still remains in include/linux/mm.h, > so you can remove it together. Good catch, will remove it too. > > Thanks, > Naoya Horiguchi Thank you for valuable comments. Best Regards, Shuai