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 A6A0CC6FD1D for ; Mon, 20 Mar 2023 18:03:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C35B6B0074; Mon, 20 Mar 2023 14:03:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 274176B0078; Mon, 20 Mar 2023 14:03:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13BDE6B007B; Mon, 20 Mar 2023 14:03:29 -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 069816B0074 for ; Mon, 20 Mar 2023 14:03:29 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 99F4740AF0 for ; Mon, 20 Mar 2023 18:03:28 +0000 (UTC) X-FDA: 80590048896.17.91DBDE6 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf19.hostedemail.com (Postfix) with ESMTP id C7BA21A001A for ; Mon, 20 Mar 2023 18:03:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf19.hostedemail.com: domain of rjwysocki@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=rjwysocki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679335406; 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=U1j6/P8OlulkqQ7bmZeujv6O1AXCl23IcsS+L7vXJYI=; b=zwuPTUxmae64ZRaExztoOVUsddCJAH/1yvvHdtlPM8TceTabqJgHv+jPYX5lt8Eg+Oci5h DK3Zt16ZNYShBtMAtOWvF3aYdaX4bxekyg+La4F8EJq49S6PxZPeXH4xKL47Pdo89gN1g8 s/UuL41RN10PZB/jYju/qoZzEx0PrkU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf19.hostedemail.com: domain of rjwysocki@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=rjwysocki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679335406; a=rsa-sha256; cv=none; b=oCJDE4jXs0PE+Wa2Sb8ML8J1WdcekJClYE4pI0UeQQmA8wDax0r0ptTU44x8v8NZgMh2xR 7qgdG8o9ivoqN5rkQTECHUHqXB533ALEBAcaizLOLjD1+Ls9sy3Fx9HZqSXbFQBcuSmWOU z0I28X1FNwLejZeANKbk11THg+nXX7w= Received: by mail-ed1-f41.google.com with SMTP id w9so50227866edc.3 for ; Mon, 20 Mar 2023 11:03:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679335405; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=U1j6/P8OlulkqQ7bmZeujv6O1AXCl23IcsS+L7vXJYI=; b=7NQgy32NhHXQQNYrguOqyMNPv5JjBX98iQpfEM7d8g3ByMyBEDGeaz7f2zq0uJNSpr VgSuizFE9JdAAkUH9bmNmMh33lqxFefyEJiuRrHTKCpB7hYz+iViTn56Mm5DpjOiyVit jlWfRy2mWVu3gA3HR8/ZhOOChHXswoFH1UlGJxc13xE5koetcPRh9pvyGdVYd3CZOt4Q dK6BhYHLBtGGMkItHLnVd4ndTKv5hJxZ6pUzYU+rHb0WH8Cs5Rffa7ls/zCvwTInaJoy wGlTagYKEfNOAKhombqUErgEXroxqTWFpgUJMVyypduChY3JTeMzrIHJHFGNksP3Zk9l CaWw== X-Gm-Message-State: AO0yUKWIuthAcS08VwbnAdEh9JyWIvIQGvYThU10lz4CEj2EWwPu4BHi 1bSNFwcPs5qwEKubvvZrAIb/EpXBErmpbDjCfLA= X-Google-Smtp-Source: AK7set8AGdLETaqUJtnhhgevZ8nVMVu9R5T4Uenh2BbM8CA/P3BMq25yTIsEdnWVxP5t/hwZ6Xl5jcM1Ls1Y84CYR3o= X-Received: by 2002:a50:9995:0:b0:4fa:3c0b:74b with SMTP id m21-20020a509995000000b004fa3c0b074bmr220250edb.3.1679335405361; Mon, 20 Mar 2023 11:03:25 -0700 (PDT) MIME-Version: 1.0 References: <20221027042445.60108-1-xueshuai@linux.alibaba.com> <20230317072443.3189-1-xueshuai@linux.alibaba.com> In-Reply-To: <20230317072443.3189-1-xueshuai@linux.alibaba.com> From: "Rafael J. Wysocki" Date: Mon, 20 Mar 2023 19:03:14 +0100 Message-ID: Subject: Re: [PATCH v3 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code To: Shuai Xue , tony.luck@intel.com, james.morse@arm.com, bp@alien8.de Cc: naoya.horiguchi@nec.com, linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, justin.he@arm.com, akpm@linux-foundation.org, ardb@kernel.org, ashish.kalra@amd.com, baolin.wang@linux.alibaba.com, cuibixuan@linux.alibaba.com, dave.hansen@linux.intel.com, jarkko@kernel.org, lenb@kernel.org, linmiaohe@huawei.com, lvying6@huawei.com, xiexiuqi@huawei.com, zhuo.song@linux.alibaba.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C7BA21A001A X-Stat-Signature: yrroa87s5cd4s9qsdw55etc1ey9nk7qx X-Rspam-User: X-HE-Tag: 1679335406-76551 X-HE-Meta: U2FsdGVkX1/0hhPvkg8jHGIkVAL9gKtqbi1jbIugxV8u9/p44bzZcu3UgCw7WMtmR8dKhuZzM87ZOMl5pnjaSbnRE5+VQeDAP5fQqh04Q9Fn5TwXiOC39D2a1FiZeSAXb7OGUXOJg4N2n6qMS034q4s1CpYIL2Sk2D6tAfFUUEishyQpDPDp3bP9EhxIQy9//hlqQcQKTFYCcBfgYKNQ7rfkd7G782C1laCf/+b2cl5PJ/gJ64gQcqPtGIl+f78uOuxitD6qB6ug5bWtBZsE0KrBXMzwJ7qTPzbKFY6wCuHAxqTAis3fju2vCID5eDCf77wM3xqsv1KXerYo6+hUwyuFA0BOphz8YlE92OQjaMOLnGOmNXlOoggWmoXQ3Qxy3r+vtQ5ty1liaExmHRCCTmyQGA6sSR0c1ctuaaWen46WV5wB3TAR5LVg5hSGYu/dyXPAr9KXYJE5mFLL+B3EmT1E7gOVVZLM1jnxfHgaKA5h4sqzuvop4U/i5JjPWNAhLaf/ehszsGuDZf0NAfQfES+tgWI+V6nd4Os9d0D4rWce1Z98poJtAKj/oU41GaMycBMUvjHDgyHn3fwwODlShQUlkjGAJB36w4pN1yVXZN1SGrkGYGtTrTf9WCzZ5Eal6gHplnhRdCbuTGWwNDlzvpiPqH9eDaY+7Bb1xcDupSiCeZY7BwuKgmAgJ2G/CFvAn73tOu7lNZI5/AZLWwysvd2ZmJt3jYH8dm5Pon7DfYPAhWboiGFT1KmLbzhjoHqsz+lO4/PX5DC9I8MG+wJU+U/rV9fvo3f1S8XTot3NlJAwEpUJkDlWPdCnsNkAr7DcFJhQauSt+5M69EvDxlkD5JBcGNMtJI6GcnzpOdoE/zaZyGCgD9P8Op1cEnIyqklRWUNv6ySzmKEKDyL8Od087TfxAHju6rSj1VfvJHjyHbWuLYO8pztn2mtScczgaQyvTuaF0CkbKf8z7atcipf j/INUTew oVxZfUbFuy6jrXhsgG4qm9Vo2A7rOiW6mBqHy/lzaX8fZ+AJ3ZGubpbIjCaSnHkPkgT99cQXrGw//EpFJzWFIThiGzCBi0MAbH0Woz4jtrItNxxvn+PegU/7SmcKuOWLTHHtxPm/VHFwLSVkUBEZepfcOV8eRMhEJPe64H+8Xtn0xo+MqKeoYRWuhso20oWO6Lojbx0UVGCC7bJDWuzaPalvNE7KHo9lFS616G6lu3WotAK9KnS+jKVtkJ4YSEqmZmpF9ShN1sNAKBXg3SYAw8GG7zAxwEZ0kdrWe1vF3Mwrv71bgnf+JPu8YhKBzy7sD/Ck+HQPf+Xyqo453yLeFsg0f1agBcNinIGGI/kHFAmzxc7Gb9yLbSWxaIvQKMNvom0IaRwSUdxFZlOHzyoawNtBwGEmfPbBPp6EuC55wbV2gYCmV6SYLIPwG8U4HfAEm/Vx2gw6Wey6Svvij86vjjolxvs04mRiRPvyxUbo6fUFMtdVM2zy6JXQXrItyUngnLpx5eCQxRoM569glYq8d+cA79kSeexEU0EeaIKMY65B0cKYNrQqdtoP4Cn96w9mRmVca 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 Fri, Mar 17, 2023 at 8:25=E2=80=AFAM Shuai Xue wrote: > > changes since v2 by addressing comments from Naoya: > - rename mce_task_work to sync_task_work > - drop ACPI_HEST_NOTIFY_MCE case in is_hest_sync_notify() > - add steps to reproduce this problem in cover letter > - Link: https://lore.kernel.org/lkml/1aa0ca90-d44c-aa99-1e2d-bd2ae610b088= @linux.alibaba.com/T/#mb3dede6b7a6d189dc8de3cf9310071e38a192f8e > > changes since v1: > - synchronous events by notify type > - Link: https://lore.kernel.org/lkml/20221206153354.92394-3-xueshuai@linu= x.alibaba.com/ > > Currently, both synchronous and asynchronous error are queued and handled > by a dedicated kthread in workqueue. And Memory failure for synchronous > error is synced by a cancel_work_sync trick which ensures that the > corrupted page is unmapped and poisoned. And after returning to user-spac= e, > 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 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: BUS_MCEERR_AO si_code to the actual user-space process instead o= f > BUS_MCEERR_AR. > > To address this problem: > > - PATCH 1 sets mf_flags as MF_ACTION_REQUIRED on synchronous events which > indicates error happened in current execution context > - PATCH 2 separates synchronous error handling into task work so that the > current context in memory failure is exactly belongs to the task > consuming poison data. > > Then, kernel will send SIGBUS with proper si_code in kill_proc(). > > Lv Ying and XiuQi also proposed to address similar problem and we discuss= ed > about new solution to add a new flag(acpi_hest_generic_data::flags bit 8)= to > distinguish synchronous event. [2][3] The UEFI community still has no res= ponse. > After a deep dive into the SDEI TRM, the SDEI notification should be used= for > asynchronous error. As SDEI TRM[1] describes "the dispatcher can simulate= an > exception-like entry into the client, **with the client providing an addi= tional > asynchronous entry point similar to an interrupt entry point**". The clie= nt > (kernel) lacks complete synchronous context, e.g. systeam register (ELR, = ESR, > etc). So notify type is enough to distinguish synchronous event. > > To reproduce this problem: > > # STEP1: enable early kill mode > #sysctl -w vm.memory_failure_early_kill=3D1 > vm.memory_failure_early_kill =3D 1 > > # STEP2: inject an UCE error and consume it to trigger a synchron= ous error > #einj_mem_uc single > 0: single vaddr =3D 0xffffb0d75400 paddr =3D 4092d55b400 > injecting ... > triggering ... > signal 7 code 5 addr 0xffffb0d75000 > page not present > Test passed > > The si_code (code 5) from einj_mem_uc indicates that it is BUS_MCEERR_AO = error > and it is not fact. > > After this patch set: > > # STEP1: enable early kill mode > #sysctl -w vm.memory_failure_early_kill=3D1 > vm.memory_failure_early_kill =3D 1 > > # STEP2: inject an UCE error and consume it to trigger a synchron= ous error > #einj_mem_uc single > 0: single vaddr =3D 0xffffb0d75400 paddr =3D 4092d55b400 > injecting ... > triggering ... > signal 7 code 4 addr 0xffffb0d75000 > page not present > Test passed > > The si_code (code 4) from einj_mem_uc indicates that it is BUS_MCEERR_AR = error > as we expected. > > [1] https://developer.arm.com/documentation/den0054/latest/ > [2] https://lore.kernel.org/linux-arm-kernel/20221205160043.57465-4-xiexi= uqi@huawei.com/T/ > [3] https://lore.kernel.org/lkml/20221209095407.383211-1-lvying6@huawei.c= om/ > > Shuai Xue (2): > ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on > synchronous events > ACPI: APEI: handle synchronous exceptions in task work > > drivers/acpi/apei/ghes.c | 135 ++++++++++++++++++++++++--------------- > include/acpi/ghes.h | 3 - > mm/memory-failure.c | 13 ---- > 3 files changed, 83 insertions(+), 68 deletions(-) > > -- I really need the designated APEI reviewers to give their feedback on this.