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 22146CE7A96 for ; Mon, 25 Sep 2023 15:01:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 714216B016A; Mon, 25 Sep 2023 11:01:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C3F36B0171; Mon, 25 Sep 2023 11:01:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58BC66B0172; Mon, 25 Sep 2023 11:01:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 49A856B016A for ; Mon, 25 Sep 2023 11:01:10 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 214CD1A0563 for ; Mon, 25 Sep 2023 15:01:09 +0000 (UTC) X-FDA: 81275432658.09.38D43A8 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 78FEC1C0045 for ; Mon, 25 Sep 2023 15:01:05 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pOGJqd26; spf=pass (imf20.hostedemail.com: domain of jarkko@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695654067; 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=Ar6vJsvAfAgIQxJE/WFggoio7iHsMq1XYC0Oa4Jnfys=; b=ZLuuEfODpjPL899OWd3LD27nVQxygCMpwW3LBzCwPRZDIpL9USNqpssKwGLtT23nE0Iz54 jQaWpxLieWqLu4fj+qpAVgEMBjiy4uQ08vwTbtwskr6Qvq3CpPsuuc7YRRy35ImUGMA9nT 58VVqQBfJnR7QMR5kOklSPZvg9q0U7c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695654067; a=rsa-sha256; cv=none; b=oEIfKtXOjqxMlSRmnvkJRz/YsUynaBxNiy/kmAVr1COJ5FY+BjPnPYSC0dxWlYtWssjyVR z2eFT2/vrUN6+x1Z0tsPmcxpyiH6ttRWLbGuIIByXDVubW7my00IV2Sb7wLBOqaZZ0lsWl yhA9WvHbJv0N5zHYE8ONrbdI4xjQXDg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pOGJqd26; spf=pass (imf20.hostedemail.com: domain of jarkko@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 7DC6DCE1018; Mon, 25 Sep 2023 15:01:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BE86C433C8; Mon, 25 Sep 2023 15:00:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695654060; bh=GUTPMlEVCxAI4XqyqO0Rqf3KWAa3RuxtFqcc2gmHP1w=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=pOGJqd26WmXtEWG9MwBrMWw6yfwLBt3Fw2NdJtV5xHWOD9eyLgAixcnEsCAXLJ0c4 7TJ5DR4cATHHVbGVNr+Q3jly+GM51Q2ZlonAvbt1NhNKnW31AscOFyc1S4kvdkUiFM NWQyqQHZ5bj9XsrhrHNcluOpevJyyVSBpDTTYVHhmrH7/OVKUA4aUkIQWJdMfNAII+ Hj8TmgzsACQLRXu6XyBY01uCt3rFzIl5g88tina/t3F2zrwDagissLn4I2EDC7UG+A Rv+zkYxxCros8yPuumZmQe9IYfZiz7vyqRTKGDzfZ1aP8XOR9pCn6QybtRugRVLJVo 0+wnUc4uR62/Q== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 25 Sep 2023 18:00:52 +0300 Message-Id: Subject: Re: [RESEND PATCH v8 2/2] ACPI: APEI: handle synchronous exceptions in task work From: "Jarkko Sakkinen" To: "Shuai Xue" , , , , , , , , , , Cc: , , , , , , , , , , , , , , , , , , , , , , X-Mailer: aerc 0.14.0 References: <20221027042445.60108-1-xueshuai@linux.alibaba.com> <20230919022127.69732-3-xueshuai@linux.alibaba.com> In-Reply-To: <20230919022127.69732-3-xueshuai@linux.alibaba.com> X-Stat-Signature: dmrqty1ath6wyco3ztmmeanbytsectca X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 78FEC1C0045 X-Rspam-User: X-HE-Tag: 1695654065-681156 X-HE-Meta: U2FsdGVkX1+yNDonEOCqCPWIgTojfLC71i3j1RtSST/kiZXvmyn6BiOjXD+on5xXkt84FC9et4x+0a5AsCyU7zP5K2jI6oWE53TzE4qQZHTeNixt0HAOXFof/uSLlbWhkHEvvbkM2vJvIYBG4y6m4t1Er0PI8iCtha33uC9Fcv7ckzP2822lKRAG9b5wwdyauc7Un4ejehYzp5pWgdI+AahratAyFJPGuN95H6mS5dT1GZx3G1S4OD3vBbGPLmxO88eLUNLAIbD5gsDlolNtkskGW0cmHyT1GfouQ4Xei+Ade5cCywU5ui/nBNhSceRNY1AUuak9rMmycwPnrOzjFJyKhRoS2vKK9EvqaAGCP0EtfWUthYcAvli3n+5TnlKVq9gFXdvhOwN4vXuTIZ41hEf9DoEjCF8i8sevi5GxoAEyM0ODDPC7IqHlfxPSBCWmgNk7wGhI4IRIBU1ieE30JadyFlg9YpHRFesBQPcHeV6swvT0ZeF72vJE1zmFoJansuMdhG16uTce+mK+j1ZLH2nEi1KrsUyFvugeqD2kJMlr9POtiKZalJGRIAKfQxr35o+cpV5cZNABnNr47zlDrxIDv1dUW8rY9OrPmVRkP7Yktu8dg3MiCr11Yu3BU7uoTaXL/e3vm6xiaEIx2fFWBbrTwC2Z4YFBIUW1UYw2u3pXcg0J/TmgdpeeMAKjD0KInZDW474RxgHxXsRMffXWFsJn7FCz8ZrKTSlcccLRTDultE/CUXFrDVwXPHxXuMRPOJ72JXajtS8Wn1N9Psc7pgKq3kHHgQRvCs+R9vhYOOqKcMw+z+ymrYag7nCQngG0xujtn+uleeNINQ3ACPesKzFwTgzUa5hmSLYGPuDqQpSP+MNwNNQzdywv8Fetvh/YGbjt1Kb7OE11vY0n11JqrjJBLBs7goh5t0EcaEfMGrZmADFUdxoIticyqf/j+fvfy7KkdUV+2uxY/mZm3m9 Kxv6cZkJ B6RCEdyEx2Cjp1lfPanLxA0yc32NcrEICY9PxMlC7S9J9iK0KI7iLlgxygfrEyVIO9I5uFrqj6J1wVVjeSIQ5agtjSde8Hl1s9drhHx0Iyxakrgt7IIyVMcp6xkxCHk21U0SAT+rB6yEipzbAK+d0q1e/RIFbFqVWT/596vZKakiDYQctpTk3iANM7ggYuzML4MN4nSmKAAwLUhxrX129Gq5V2FPapBHAQGklWsqsLqkA+ozshP3yhc3WxRt9XLmewY+dVz19h0Rv21M= 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 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 a= nd > 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 whi= ch > triggering a page fault in which kernel will send SIGBUS to current proce= ss > due to VM_FAULT_HWPOISON. > > However, the memory failure recovery for hwpoison-aware mechanisms does n= ot > 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 notif= y > 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 SIGBU= S > before ret_to_user. > - valid asynchronous errors: queue a work into workqueue to asynchronousl= y > 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 syn= chronous 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. BR, Jarkko