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 21050CD3427 for ; Mon, 2 Sep 2024 14:19:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA5F66B02A6; Mon, 2 Sep 2024 10:19:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A391A6B02B1; Mon, 2 Sep 2024 10:19:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CE926B02B2; Mon, 2 Sep 2024 10:19:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6851F6B02A6 for ; Mon, 2 Sep 2024 10:19:35 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2373B1A1DFD for ; Mon, 2 Sep 2024 14:19:35 +0000 (UTC) X-FDA: 82520006310.27.C6E6F0D Received: from esa9.hc1455-7.c3s2.iphmx.com (esa9.hc1455-7.c3s2.iphmx.com [139.138.36.223]) by imf07.hostedemail.com (Postfix) with ESMTP id 82A4A40022 for ; Mon, 2 Sep 2024 14:19:32 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=fujitsu.com header.s=fj2 header.b=tM9ZPO8E; spf=pass (imf07.hostedemail.com: domain of ruansy.fnst@fujitsu.com designates 139.138.36.223 as permitted sender) smtp.mailfrom=ruansy.fnst@fujitsu.com; dmarc=pass (policy=reject) header.from=fujitsu.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725286698; 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=WONpyePEUNpC4rt3zeqL5WSYjjJweQXFmwh38iJ0sB0=; b=AxC9nh1Pzd76drlH4D006bUl2T+hPruutL1qGOWxQGLWdQNMoY3Atl+I1o8G85Xue4Hjr6 uRIKVjGlc1U8Tpet2mXm+hGvs2PW40fntSKwqr1fcOLgleTpTqQ2Xy+rnwy/ctE5tX7Qgn wtbbjOb/FMThbFnbIeH+SRH6VBtRjhA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=fujitsu.com header.s=fj2 header.b=tM9ZPO8E; spf=pass (imf07.hostedemail.com: domain of ruansy.fnst@fujitsu.com designates 139.138.36.223 as permitted sender) smtp.mailfrom=ruansy.fnst@fujitsu.com; dmarc=pass (policy=reject) header.from=fujitsu.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725286698; a=rsa-sha256; cv=none; b=0aGCAoBUpcN37bQ8V5KXBH8GFFDUrkWd1FTdsbtP876asVby2xdhhk7dZj7RrsydZxHzOo xgvddbeZyDugpFq52wAspKsPUSINzgGSgPXuWIQbHXqe0eXQHI0patL4MUTnNNpPiyDGMq V5q1TuEAcFZtm2pkVM9ZFEMMBzdSJ8c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj2; t=1725286772; x=1756822772; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ZkWv2QJf7NlJ00mCSywvA3GddH6obDZjGitEq5QIKtQ=; b=tM9ZPO8EqV8utFZTFIv+2HIjJSu2aRGeSlHxJ4rK90+6NwNr7ys9bFYt CFZvsZkj7QJ9JwrP7qC1l0YbX3ctSumKsL71iwVpL8ugbooUDIn68gn+Y DVTYeAY3yDwQtZzCQz+SkXuR3UWfMEEGeB/ovpDT1z5PNCCBxs5RA7SWG ru5ctR3wTZb71Emvxwak+m/WfdPAPYU60eVQBABeSxxt64572uP0lobzP JsIlhVi4Vuay/BegYz6NmCktajWXGK475ITjT9q9s1ausbtONPeaedVGP 9Yc2ywyHWXoYO0+vj0Bdz2tY2hL/5tw2YF9QwkN1pyJGy8q+Mj5Gty7MS Q==; X-CSE-ConnectionGUID: 0F879UMURYCH6IWwKdT8zQ== X-CSE-MsgGUID: CvaphD+9RNuMjjXr2R8R9g== X-IronPort-AV: E=McAfee;i="6700,10204,11183"; a="160728195" X-IronPort-AV: E=Sophos;i="6.10,195,1719846000"; d="scan'208";a="160728195" Received: from unknown (HELO oym-r2.gw.nic.fujitsu.com) ([210.162.30.90]) by esa9.hc1455-7.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2024 23:19:29 +0900 Received: from oym-m3.gw.nic.fujitsu.com (oym-nat-oym-m3.gw.nic.fujitsu.com [192.168.87.60]) by oym-r2.gw.nic.fujitsu.com (Postfix) with ESMTP id E26F4D4240 for ; Mon, 2 Sep 2024 23:19:27 +0900 (JST) Received: from kws-ab3.gw.nic.fujitsu.com (kws-ab3.gw.nic.fujitsu.com [192.51.206.21]) by oym-m3.gw.nic.fujitsu.com (Postfix) with ESMTP id 348A4D7627 for ; Mon, 2 Sep 2024 23:19:27 +0900 (JST) Received: from edo.cn.fujitsu.com (edo.cn.fujitsu.com [10.167.33.5]) by kws-ab3.gw.nic.fujitsu.com (Postfix) with ESMTP id BB44D20079564 for ; Mon, 2 Sep 2024 23:19:26 +0900 (JST) Received: from [10.193.128.195] (unknown [10.193.128.195]) by edo.cn.fujitsu.com (Postfix) with ESMTP id 889C41A000A; Mon, 2 Sep 2024 22:19:25 +0800 (CST) Message-ID: Date: Mon, 2 Sep 2024 22:19:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] cxl: avoid duplicated report from MCE & device To: Jonathan Cameron Cc: linux-cxl@vger.kernel.org, linux-edac@vger.kernel.org, linux-mm@kvack.org, dan.j.williams@intel.com, vishal.l.verma@intel.com, alison.schofield@intel.com, bp@alien8.de, dave.jiang@intel.com, dave@stgolabs.net, ira.weiny@intel.com, james.morse@arm.com, linmiaohe@huawei.com, mchehab@kernel.org, nao.horiguchi@gmail.com, rric@kernel.org, tony.luck@intel.com References: <20240808151328.707869-1-ruansy.fnst@fujitsu.com> <20240808151328.707869-3-ruansy.fnst@fujitsu.com> <20240827165255.00003184@Huawei.com> From: Shiyang Ruan In-Reply-To: <20240827165255.00003184@Huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSS-9.1.0.1417-9.0.0.1002-28636.007 X-TM-AS-User-Approved-Sender: Yes X-TMASE-Version: IMSS-9.1.0.1417-9.0.1002-28636.007 X-TMASE-Result: 10--18.722600-10.000000 X-TMASE-MatchedRID: qA30kLX4rkePvrMjLFD6eKn9fPsu8s0a2q80vLACqaeqvcIF1TcLYLBk jjdoOP1bW9EH4+AJvKPWEKq3/x+jsOZusStRKBV2lOneJcroAxQEa8g1x8eqFzKIerHAhfYxh4A 8/yPGZNapvxnoY+yIonXOnTupNIIg0ULUiMMnBpvEOJqSsn5KmZQ7eT0DII9NfnzRct83gQIJfS FgccfpAR+fvjkvoc3Be52pOBC+4eHTVE410k90AWQFd4bOnrT64XnbArnSCLHkMnUVL5d0Ezje3 avJWBBRdOlApyjqZMKIT8eUrs+4RRs7n0Ur0F2YRN+FMKVZBhEQOcMSo0926lcZNuxCoduS7bVh 2RA8dMz3SzCPT5sXYys9U4Zn7lQDVOc6pZRHw9cmZusHWPhfCk3yuY9BGW8rsqiKlYBJQxg0Oxd vWc671FozlTt1FeqbX7bicKxRIU23sNbcHjySQdigzzbKqYUy+gtHj7OwNO0YzpbdT4uedzdKAe VgKQLGIiCPMSPC78UIet2iW5cw1yy8MXciL+hj X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-Stat-Signature: wym7jwgy5uyxqoxkb9kp9pqboz5ounqz X-Rspam-User: X-Rspamd-Queue-Id: 82A4A40022 X-Rspamd-Server: rspam02 X-HE-Tag: 1725286772-202159 X-HE-Meta: U2FsdGVkX19pXrYTVwNFoqrglQYDvlIBspaGSJxqrBtdpxao1xrmsvfZTs6yTq2Z409Dmxkq6ILo7O3BXSt79rxEvdHtOZxzsaAljOoLGVPxh4qHV8qClOt5EsY08ukNuf8BtIgJe3Oy1MULMw9HVSW9qFDeGlI5iG6x8VZsaFP7qypLaEXVKL7TfeTOVtEi2nxhmNdJMWnrsWJIG1ZE0hFvNIs9wiNMN/GipaCaBLupD5oFxyXPXfBGMCKGcAL6s3B9oSnCLtQ8Lgr+yqt5hYsmaEG8bHmThA47KuBm8VJgF8PBlBHVvJ6Zcjw4Dvmvepx/17RWIpcHE+1KLcD86/q8fWd2GnrOcej3IHPqZWEJRdZyeo5sHOMpxRzQQHX7TPwjfQ96NqqBqyR2MR3lJs7Xg4FP0v36nfk0OynQNp5ZOnuCCeKsvaKB1cagoUfR8v7Ls/QoG7SEtkY5z5EHwdu5O5PGMA++brHBgzdSGd5lx6R0xSAG6QTLIrRxdH6b9KlA4BNqO3OkgLw3P63+zHa0nJscL0/JmnO8PrY3DpTN4ubx2sKD8P7+XB6hjAcswun98bj0bTf7XrlCEbo/DqW4hf/ihIKRnYnYeRPjW82A2V0H+ahE89N8u0TanUlAPeckb1YWgkkGQF+jdwbDDdljwA+1MjYuQ+A1W4H9Ki8E3wCUBUPKrw7hmeIOoEOy6UbbP2HMmD5lTXLK5A6pSoSq7Pqc0udR9iYvgellGh1z/MipAo+cyxmb6g9RpUIinwuVoje5AlOEVBoLsE29mK1tQxcX/+uH2wbCUcfNuwSpv2Y80XlPrMd1mjQ0Bn0TyWmSGujCHW1VSuj7QSCbDClw6jhHZ8J8trAOFclvKIUi1aMdTt8b2IUzXn20VZsEV1vqYLbWdXgjuJbDbsjEoNBS+xLAhPbQV2+5wiWn7jAYecyrFK77WK83nsrJwW4d7rnf1mK0UYf62Pcoq/K vpdQI6s9 ZSqofOSnALznTfgmpJ9DaNkl4DHup9GDSHdCNX3Eb7SidoXchL84ezyiJTeEdAjzRMjpCAyvSu+T9dFhs8OgarqUpFrPv331iWcqAVi6shugoCEL9EFODaFOMWlyEp/emXvQ+oQrVErrkUhz6F6DMuEgHI7x3400txZNtN2Srn72CYn2xM8tdBvIikYQoNdKtHMjfF7md2h4YpSo5h/wZlj47LZ2KhHxbfYaC4STVoy5Wm60ZXDd0n74UnTPnjJ1Ex5yhoZnUvLIWzm0jO9dR/J528iNkBKXQuoOKjvqgfToCa1Oq27PmRhujebn3H0pfn+AcocuPXDRBdkIcgh64DfdJeIsQjTDLOgm2nmdiKEFFLjIsedFRozCR50n4C84N2b6PJwNSzfpN8EnaYIxLZD5cOt2XtW2Unig/ 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: 在 2024/8/27 23:52, Jonathan Cameron 写道: > On Thu, 8 Aug 2024 23:13:28 +0800 > Shiyang Ruan wrote: > >> Since CXL device is a memory device, while CPU is consuming a poison >> page of CXL device, it always triggers a MCE (via interrupt #18) and >> calls memory_failure() to handle POISON page, no matter which-First path >> is configured. CXL device could also find and report the POISON, kernel >> now not only traces but also calls memory_failure() to handle it, which >> is marked as "NEW" in the figure blow. >> ``` >> 1. MCE (interrupt #18, while CPU consuming POISON) >> -> do_machine_check() >> -> mce_log() >> -> notify chain (x86_mce_decoder_chain) >> -> memory_failure() <---------------------------- EXISTS >> 2.a FW-First (optional, CXL device proactively find&report) >> -> CXL device -> Firmware >> -> OS: ACPI->APEI->GHES->CPER -> CXL driver -> trace >> \-> memory_failure() >> ^----- NEW >> 2.b OS-First (optional, CXL device proactively find&report) >> -> CXL device -> MSI >> -> OS: CXL driver -> trace >> \-> memory_failure() >> ^------------------------------- NEW >> ``` >> >> But in this way, the memory_failure() could be called twice or even at >> same time, as is shown in the figure above: (1.) and (2.a or 2.b), >> before the POISON page is cleared. memory_failure() has it own mutex >> lock so it actually won't be called at same time and the later call >> could be avoided because HWPoison bit has been set. However, assume >> such a scenario, "CXL device reports POISON error" triggers 1st call, >> user see it from log and want to clear the poison by executing `cxl >> clear-poison` command, and at the same time, a process tries to access >> this POISON page, which triggers MCE (it's the 2nd call). > > Attempting to clear poison in a page that is online seems unwise. > Does that ever make sense today? To be honest, I am not sure about this. Even if the error from CXL device is recoverable, we don't reuse it again? > >> Since there >> is no lock between the 2nd call with clearing poison operation, race >> condition may happen, which may cause HWPoison bit of the page in an >> unknown state. > > As long as that state is always wrong in the sense we think it's poisoned > when it isn't we don't care. The 2nd memory_failure() need this state to determine whether to continue its process or return. >> >> Thus, we have to avoid the 2nd call. This patch[2] introduces a new >> notifier_block into `x86_mce_decoder_chain` and a POISON cache list, to >> stop the 2nd call of memory_failure(). It checks whether the current >> poison page has been reported (if yes, stop the notifier chain, don't >> call the following memory_failure() to report again). >> > > If we do want to do this, it belongs in the generic code, not arch specific > part. Can we do similar in memory failure? Yes, I saw the build error. Will fix this. > > To RAS reviewers, this isn't a new problem unique to CXL. Does a solution > like this make sense in practice, or are we fine to always let two reports > for the same error get handled? > > > Jonathan > > -- Thanks, Ruan.