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 83485EE3F2A for ; Tue, 26 Sep 2023 06:38:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 102048D0071; Tue, 26 Sep 2023 02:38:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08BEB8D0005; Tue, 26 Sep 2023 02:38:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6DDF8D0071; Tue, 26 Sep 2023 02:38:14 -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 C4B518D0005 for ; Tue, 26 Sep 2023 02:38:14 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7FC3612110C for ; Tue, 26 Sep 2023 06:38:14 +0000 (UTC) X-FDA: 81277794108.29.5A7988F Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf01.hostedemail.com (Postfix) with ESMTP id 209474000B for ; Tue, 26 Sep 2023 06:38:10 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.119 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=1695710292; 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=qdsp+dyyMF0Ar+GD5nWU2SWJOu4S/HoF+q3igmDjPj0=; b=q+t2M5yqv8/NpNxxHnjaZZENSh4WKzZQ16oDDJXsvKrtOvTrypgT4btejv7VdfXwCfDw6l yvhQ42ticfofOCP0uOjfJNs6X15uSl2T1HrFd4a9aQeJvlsDHZCTyqtUI55s9CDTp0Zo1M p++1bEeONWcgsPmXRw9UnJnEXabBiRk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695710292; a=rsa-sha256; cv=none; b=O35lNlZQH2e2EHaVBV5JS+DB/HzIwoM4qL8//nunN0oq46zQR0rM2CWBJ9p0ATPavkuuqR vgjN9vcuFxVIln6EP0+tl8A4SNcLZ3S2YconTIkecar92JDzLge/oUexEkbLpdN8e/09z9 YnVR6Owro5CFOxyE8RG/HvcAh2D4ZzA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.119 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=01201311R341e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046056;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=34;SR=0;TI=SMTPD_---0Vsvr0J9_1695710284; Received: from 30.240.112.49(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0Vsvr0J9_1695710284) by smtp.aliyun-inc.com; Tue, 26 Sep 2023 14:38:07 +0800 Message-ID: <078b410f-e3b2-0355-d993-40ac46b99870@linux.alibaba.com> Date: Tue, 26 Sep 2023 14:38:04 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [RESEND PATCH v8 2/2] ACPI: APEI: handle synchronous exceptions in task work Content-Language: en-US To: Jarkko Sakkinen , 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 Cc: 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, 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> From: Shuai Xue In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 209474000B X-Rspam-User: X-Stat-Signature: grkhfzq13bydagj473hf9uunyo8m95rq X-Rspamd-Server: rspam03 X-HE-Tag: 1695710290-257138 X-HE-Meta: U2FsdGVkX18gH98SgsZ/Ou7kr4BiLYFlT7sFHuKIHlSyy/Me2+Y4uDdiSMdjjPfb0ODjhQkeOQNu1eYIMVahTW8NqfSgp7eQQyF7d+RLNF4Oca8HaIJBhTbSlQtkYo0HmjZ4gWBcxGNnv5cSlwcjyKdd0z9lt8UGVQoff9AGppesd1kph2MQUonKJb24+wK/x0ggaQ9ZD+oFiWQIf04hlRL0uuLa7QPmkI0HGmwedoJgzYNWfZi0h7XkVPBLKHTxIZqY0Grz88XdNkFS37X4fjJ9GIoaxey6Qy21iaDJ1a+bbZPpQ8do1LAHaRPmm/pd7yvk7o7QivGMnB66CQMjzN/9bU5dsQVWYXEcOjLKLZKIb8eJFwc7as9Zjl9tG7HGJOEIN5vlrcCAXJKk1D+66WeE376v17f8Qj87bKhsYzfpRJWDKO4l13wO3LrP3aA9O8J8W5QktGdWSe4DGhbS3qtAgsQA60ou2CP/jxMxV9tU8GaXY5vA4crGOMcDk8Y/ACepFAElcRB+47vg742hlr67nj5SohN3BFqelqy6QGYXSLkybO/kr8RTIRsHe2NaiL38G9/365dUSbIGBLRuGg04plLbcdTe3MbHaWTV48RjyLtkcZQCI5slhl5RYTUaiVQZRB8/urZuT94HbgTrAL1uvU/aMHjRLQP9Fs4Hct0yOhW3dRdpEDcoEJOEToCSwXWJ+tViUPOlUI+TbGe9DY7fMzMQ5C1eEweyXsESuXxlowuAj0kSZ1jChT7CvbTo/VcczmWeseWSBpSU1RQY/3fV/NrCY3NEjp9gdsIlUdAzlL/YpV2na7lIhq/t3XSoHpUdzA5nC3WfNsj4yERl/T7QCsSRZPhzZcXaVAyVwW0GARq1oWTnojYEfWiESnnWb2W2LvhAZdjcRhsiyLYrJ3ApJZz0dJpnSQejEWdc3F/thYRFuxQxrfV09XyYbBDED+8MxOQB7XWK33FS/GT 6yj5kUTZ N8rhctMYwBklyi30PjWVmISc/wMPyGxJVJe0r12fR77vseGl1z3vcLjxw/Rlyw9pTMs8O6Y+dpqIvAvRCbSGKFcu3XFkpyhevfFAeyhlj6daaX5T6GVitMjv5Dg== 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/9/25 23:00, Jarkko Sakkinen wrote: > On Tue Sep 19, 2023 at 5:21 AM EEST, 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 > > Did 7f17b4a121d0 actually break something that was not broken before? > > If not, this is (afaik) not a bug fix. Hi, Jarkko, It did not. It keeps track of whether memory_failure() work was queued, and makes task_work pending to flush out the queue. But if no work queued for synchronous error due to abnormal branches, it does not do a force kill to current process resulting a hard lockup due to exception loop. It is fine to me to remove the bug fix tag if you insist on removing it. Best Regards, Shuai