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 2A8D0CD13CF for ; Mon, 2 Sep 2024 14:03:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F94C6B00BA; Mon, 2 Sep 2024 10:03:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A9B18D0098; Mon, 2 Sep 2024 10:03:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FCEC6B00BE; Mon, 2 Sep 2024 10:03:20 -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 5D6CE6B00BA for ; Mon, 2 Sep 2024 10:03:20 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 02B65141D58 for ; Mon, 2 Sep 2024 14:03:19 +0000 (UTC) X-FDA: 82519965360.19.F4741EC Received: from esa11.hc1455-7.c3s2.iphmx.com (esa11.hc1455-7.c3s2.iphmx.com [207.54.90.137]) by imf04.hostedemail.com (Postfix) with ESMTP id D9DE24001D for ; Mon, 2 Sep 2024 14:03:16 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=fujitsu.com header.s=fj2 header.b=n2xKAE3J; spf=pass (imf04.hostedemail.com: domain of ruansy.fnst@fujitsu.com designates 207.54.90.137 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=1725285673; 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=u8vQVC8sl+DZgbt/u9bmZqQkzlmgDUmWu0PLBv1kpCw=; b=BE15VJf9u4r/a/Ym6EVDcVh9WinZWC1aWVU988w/o7yyzrmfpkbC/8b3FA8DMO8NQklswY JPrfVsEmtfE4sgA6YIJYuFrZ/h6ThL9VZZ0YV3gam2v3BTqZHoo3NxyUwGqHgQEiJouODz pPWERTQgsbnmfvgqipmBj3UJ65ps+pQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=fujitsu.com header.s=fj2 header.b=n2xKAE3J; spf=pass (imf04.hostedemail.com: domain of ruansy.fnst@fujitsu.com designates 207.54.90.137 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=1725285673; a=rsa-sha256; cv=none; b=YD1RZB/dz15mrfr3m08oYbRgUNNcrp/V0gUBy2JomJtY3v3VvyPjQdMoHVyZIv7zi4IaNq fQ4t80V3M+TIGRs7hOQlzW1fmMfj3GpQAvRygydvE+1KNLJYTYuw8pLWeORAACU/+shnKN 4pr22FrrX9LDpxHohiRs5Vw/nJBr4Fw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj2; t=1725285797; x=1756821797; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=GX/6obQSv/WJf/FAn9TAasDUp/DJhqEtQ4ON1iidy0E=; b=n2xKAE3J9fwDgwkMdEN1Hz3ET5BScBQnXGWghKTZPwSVUxWd7qdskkK2 ml2uKs+N4xDtuHMmB0OoqiD9fPv3cbmqQWu3iAOADXjjTYpmvtjyKiJzY 1qoGVs8pxoMZv0PC0lPTCevAWYq0hjH2/mzVV3kmSMX696QaeTAylwnGD epiZgFyueiTS42B4PNPfp8uhmvdhpuJ5m6VAp+CGetIkP4XCeBfH4ZtOh aas85rg+Qsyha2sjoXmjQ+Y8IgrNCudTU34wAGg18EMXNy5wES6SnZ6Ig F/le0sPyLWLeTlmdlei5YsGtrn1S/pxNrCRlnxNd4rTscbMFUX+kP22fF g==; X-CSE-ConnectionGUID: bpCz0euOS2695DeOwQokow== X-CSE-MsgGUID: uZhR9eZTSOuvvwiQs28pKQ== X-IronPort-AV: E=McAfee;i="6700,10204,11183"; a="151868573" X-IronPort-AV: E=Sophos;i="6.10,195,1719846000"; d="scan'208";a="151868573" Received: from unknown (HELO oym-r3.gw.nic.fujitsu.com) ([210.162.30.91]) by esa11.hc1455-7.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2024 23:03:14 +0900 Received: from oym-m1.gw.nic.fujitsu.com (oym-nat-oym-m1.gw.nic.fujitsu.com [192.168.87.58]) by oym-r3.gw.nic.fujitsu.com (Postfix) with ESMTP id 9C847CA1E1 for ; Mon, 2 Sep 2024 23:03:12 +0900 (JST) Received: from kws-ab3.gw.nic.fujitsu.com (kws-ab3.gw.nic.fujitsu.com [192.51.206.21]) by oym-m1.gw.nic.fujitsu.com (Postfix) with ESMTP id D2F41D88A1 for ; Mon, 2 Sep 2024 23:03:06 +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 5E76620079561 for ; Mon, 2 Sep 2024 23:03:06 +0900 (JST) Received: from [10.193.128.195] (unknown [10.193.128.195]) by edo.cn.fujitsu.com (Postfix) with ESMTP id 79DEE1A000A; Mon, 2 Sep 2024 22:03:04 +0800 (CST) Message-ID: <05811930-8fa9-42f8-8034-6f0945b103fc@fujitsu.com> Date: Mon, 2 Sep 2024 22:03:03 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] cxl/core: introduce device reporting poison hanlding 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, shiju.jose@huawei.com References: <20240808151328.707869-1-ruansy.fnst@fujitsu.com> <20240808151328.707869-2-ruansy.fnst@fujitsu.com> <20240827164610.00002f4d@Huawei.com> From: Shiyang Ruan In-Reply-To: <20240827164610.00002f4d@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--17.417900-10.000000 X-TMASE-MatchedRID: xnGAJ48IopiPvrMjLFD6eKn9fPsu8s0a2q80vLACqaeqvcIF1TcLYLBk jjdoOP1bW9EH4+AJvKPMrGM6h+7YUICoSWHZmQrDKiJEqUFWRghZDdHiTk9OcJDHQ2MaZXz4jK1 xN9jQWTnOpS+AHyEE2hcHv+b01YKmYY3ozW+EngffqVBdB7I8UaPhbuuLYFOYc/T3GfQUvxlxtF 6KhREXKa2fCRhYzsoC+5kmiwJAxT+hxhqB2G57XTe9MF4SNA1+ocSvEPKGO+fAu8ilngS2RRRcq LOELivDxSb5KmzgaAwv1d8yhDAVO4xxTMlLewfdh1CxlJlk5RpJ0h0KLwFrgJm3OIVSf4P5slCg QfGYOCnzgfRAkJS4G6EfeQTpODV8uybvDkIalGAdZEkR8Y/meYQg0F6EHA2oS1jK4vkKprF5GDv /ZOF4Nm5/m6vlvI+l0CcTQ1zeUMSPfh1s1LkJMFlGa4Om1d9neF6MevMVZUBncSzHLoRambTLcN rcH2Gr585VzGMOFzDYh0PvnvUH8EY41YX/o/8KDZX99HwFDsIqtq5d3cxkNUB2W41yROPGyZQsj JwjJMsteacMfEd8nWcmUNFBCcvs6v+KAQNhbdM= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D9DE24001D X-Stat-Signature: gtcpajcwusrw9e5iaag7y6jgmpto1smh X-Rspam-User: X-HE-Tag: 1725285796-596982 X-HE-Meta: U2FsdGVkX19eDY5whxJwizJoaPE9qL12yZsZM1YO5+qH2kd8vQiOsUCOGxiAYOPKTFRsGdBnoitDO4hGqxlmNdrDghuYk7BMWKov9HgFUZyvfoGxU+pACzPA/6nBp6EVH6Z/SRBIDY1KFe9ye484qplBSx5HprO6vfL309YVdus7qp3VvlNQmkJelt9+06VsAO6DKeP9UDpxYp+XrlqLRR4kC6QO5BpsHqntWm+Rj8iRgCZyu7UfW6bVuda1ZsDzvMhk+G5ijonezzP9QVZxXBJkfD0sMydidV24hfHjwdoV7EdgFuJdkrG0nq2ETgOJ5kM53ROPqtBon9BDbFQ2Lx6IC63hixH2I/UCQwj8dkDpAHQJ53c0oNzmheuWXyoXwZFb5cfHWs1/8RRZc1Tsvztq1Q0SNi6ImHwz+kjozS512Mxq6CThba5b4C9CO4dfb6t+r0hz2MQ3enDWylzQ20eppVQ8FRByir1FyTNK1x3XGi3QBm3wwWQJ1ZpDoY44fL4loZcVJ84YH9xuNynV7+B0ecUZR1E5wyxmYWRt6UNNVM1FHSg1/MjkHVYVSOddHljCvH8NcpX0UzjorjgNTR+mwq+hRDHyul8ib2dTQMUrSxbDfmErvrLN4T0JpHOJB4ka9AB9Sc7s7bNeFzyzYOKZd9ezyfUGAgrSx7tDL5ogUy9425TmEOlJ6IfQEwjfweYJ/ai+wzKlWn4PBp6FSGtbFyLcOhfVrNxFULZZ9l9MMoU4UuMkkXM9FXuRO1hK6ludQiSMSlNvplJ3/SRq8vXGstcXLwA2PxIfgBkgVEKa00CuGlITiTru6h1sVdppQ/OBZnXJz6vFFXAg6HMgG3+gyWpNRONHYaYhOgH8A9XHRorgo+1b2P/K7QObWNcNaH9ArBgfqOO/vBrlzGMPyUyzrIwJE2ZNuM1Wl/SLL85bUocxXwLn8/s9Px5OW2tOk7jJcBC2gy6isl9Yt4X /DjiBHZA vMHuDJ7Y61KwEPado3O1/ZUw+G18kbsRiLJkvq967S5bpMImJCu/MgmB4YaDS8wf9edBfXBYjF71jIHgpJAS7WS1rklB0rYNuM6Z8EmCgobcNU4jcuNekeEUByZDLANBLASPc5Aa3k1klfpSgfJ9B4M/8yk6grCDoW+1gTFtm534tIuDHyNJCco2U48brukjOlfSvx60jxZN49c+Fgpvn2j/BQrErTYL8KI+0+lmzT2Rvu48u1BWJaXX+5ljoJqltsITzzTkEYeNJJYOgPhPdMNwlCkI7hxMHa9jGpMEUPKnzv8nFOR+nWHhXZJMWW1ULuG2Qje3sYwGgKukJzozdP6VbtPJ/j6xVq8i2iobcDLRkCKp3bjgmL5Cuu3aWL8xKn6pRRJ+7On/rLCdXApDkRySciIL26vUTHYiJ 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:46, Jonathan Cameron 写道: > On Thu, 8 Aug 2024 23:13:27 +0800 > Shiyang Ruan wrote: > >> CXL device can find&report memory problems, even before MCE is detected >> by CPU. AFAIK, the current kernel only traces POISON error event >> from FW-First/OS-First path, but it doesn't handle them, neither >> notify processes who are using the POISON page like MCE does. >> >> Thus, user have to read logs from trace and find out which device >> reported the error and which applications are affected. That is not >> an easy work and cannot be handled in time. > > These are async reports, so I'm not sure what 'in time' really means here. 'in time' may not be appropriate. I think 'ASAP' is better. I just want to say: comparing with users finding out the errors from trace logs and notifying apps manually, kernel handler can do that automatically and ASAP. > If we get synchronous poison from a processor access it will be handled > via traditional means (MCE, ARM SEA etc) Yes. For FW-First path, MCE mechanism can cover this. But for OS-First path, errors can only be traced, then logged by userspace tool like rasdaemon. We hope in OS-First path, kernel can handle it like MCE does too. > > Whether to handle async error reports (typically from scrub or because > the memory device received poison from someone else) the same way > should perhaps be a policy decision. It should match what we do > for firmware first async reports though (any policy controls make sense > for both). Yes. In OS-First path, I think it should always be turned on. > > An example of this would be that an host OS might attempt a polite close > of an application might attempt a polite if we know there is poison > somewhere in a dataset it has access to. If that poison is never seen > synchronously (because that data is not read) then it my close > successfully rather than being killed. According to kernel docs for 'early kill' of memory-failure, I think it's suitable for this case. > > If it's injected poison and we didn't see it synchronously we might > well not want to kill anything. Agree. Injection APIs are used for debugging, not a really HW poison. > >> Thus, it is needed to add >> the feature to make the work done automatically and quickly. Once CXL >> device reports the POISON error (via FW-First/OS-First), kernel >> handles it immediately, similar to the flow when a MCE is triggered. >> >> The current call trace of error reporting&handling looks like this: >> ``` >> 1. MCE (interrupt #18, while CPU consuming POISON) >> -> do_machine_check() >> -> mce_log() >> -> notify chain (x86_mce_decoder_chain) >> -> memory_failure() >> >> 2.a FW-First (optional, CXL device proactively find&report) >> -> CXL device -> Firmware >> -> OS: ACPI->APEI->GHES->CPER -> CXL driver -> trace >> \-> memory_failure() >> ^----- ADD >> 2.b OS-First (optional, CXL device proactively find&report) >> -> CXL device -> MSI >> -> OS: CXL driver -> trace >> \-> memory_failure() >> ^------------------------------- ADD >> ``` >> This patch adds calling memory_failure() while CXL device reporting >> error is received, marked as "ADD" in figure above. > > Typo in patch title. handling Thanks. > I've also dropped qemu-devel as this doesn't have anything to do with qemu. > OK. >> >> Signed-off-by: Shiyang Ruan > > Experienced RAS folk in the CC, how do you want this to work for > asynchoronous memory errors on CXL devices? > >