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 527F3C02180 for ; Wed, 15 Jan 2025 11:35:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5111280006; Wed, 15 Jan 2025 06:35:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD90F280002; Wed, 15 Jan 2025 06:35:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA0A2280006; Wed, 15 Jan 2025 06:35:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 98260280002 for ; Wed, 15 Jan 2025 06:35:36 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4DB021C7FCE for ; Wed, 15 Jan 2025 11:35:36 +0000 (UTC) X-FDA: 83009481072.13.000B9F3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf01.hostedemail.com (Postfix) with ESMTP id A3C444000E for ; Wed, 15 Jan 2025 11:35:34 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="cxAa/fZn"; spf=pass (imf01.hostedemail.com: domain of mchehab+huawei@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736940934; 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=fLnUHz5oryGGwT3tfpsSxyDvkgvPZnvIGOU3STUNyZ4=; b=pyUGoH344lN9uV8xuEjoRYb57ihSJvhUn2tkrukBNOodLH6CCllRnXURnuMOmwiuDE/TGA G4Ub681WNUkGGZ0AWRhU0m5triKlTQrPUa9ugFAaS0Z2P8kcIlTXSdZdITL8xrbo5DMwpA VUqvnDV9lfMGQt9PCv9XUFHzXllfTB4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="cxAa/fZn"; spf=pass (imf01.hostedemail.com: domain of mchehab+huawei@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736940934; a=rsa-sha256; cv=none; b=1nrP07GprIv3b+dd1QUm+mJfP/x8Elg3B3CteZWm0EjsUUGbGbq/AXkvSBNZSSiCre88g0 NirVcM0Et0bt8AWNM/oDBRZJWG/NQyluAUw5UV6ASYI/7RIfw1nY1Cp3XP6nwvm84Kns1J /70DVZ86g9JEmGgFhWu/2qNpWWzTUmo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8FF95A41DD6; Wed, 15 Jan 2025 11:33:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10462C4CEDF; Wed, 15 Jan 2025 11:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736940933; bh=0GsDX1/RuLPGLESvD1Mlrazvy4i984P60lfK4cHzDVM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cxAa/fZnkgoBmd79zeqbHUiOpU1wthso51T9zsiTKQiFBqoKsRbJYsdABlUu/Bd3p jIxohZx4PK2YGuyhwce0xSOx9X//1PxTJcveTF2eu0ytA5NAc7bxGL8s148vSbQGjj NsZuz1fl+wYnOSWG6gUk2Zxmeq6qIToOyYFTT5gU9mjDxBrB0Rkl1ESH3GFiM3Rfj9 uKtXFCDudeOcuuQBRiIj5Cfe41gK1YCfmNta/ghWmP+jSxMNJLEb6bEtBWlWN3wf5K zrSi9LOJVAyckZf0044niFYEuDsmmjiVd5piqOuvOT6C16dsMCfilmghHV/baPomb5 RibA1bHNoqtwg== Date: Wed, 15 Jan 2025 12:35:22 +0100 From: Mauro Carvalho Chehab To: Dan Williams Cc: Jonathan Cameron , Borislav Petkov , Shiju Jose , "linux-edac@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dave@stgolabs.net" , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , Roberto Sassu , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature Message-ID: <20250115123522.2c73fa2b@foz.lan> In-Reply-To: <6786bc792c66a_20f3294ce@dwillia2-xfh.jf.intel.com.notmuch> References: <20250109123222.GBZ3_B1g3Esgu1-MPi@fat_crate.local> <20250109142433.00004ea7@huawei.com> <20250109151854.GCZ3_o3rf6S24qUbtB@fat_crate.local> <20250109160159.00002add@huawei.com> <20250109161902.GDZ3_29rH-sQMV4n0N@fat_crate.local> <20250109183448.000059ec@huawei.com> <6780610bc33e9_9b92294cd@dwillia2-mobl3.amr.corp.intel.com.notmuch> <20250110110106.00006cd5@huawei.com> <6781a3dfa53d6_2aff429471@dwillia2-xfh.jf.intel.com.notmuch> <20250113114026.0000548e@huawei.com> <6786bc792c66a_20f3294ce@dwillia2-xfh.jf.intel.com.notmuch> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A3C444000E X-Stat-Signature: jrhxnu15oyg48c5kciyofejhgr5kuw9u X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736940934-114362 X-HE-Meta: U2FsdGVkX1+IMgwLsWKl4vP/aH71k/E+uQSkmFFro/fhjEOAHcnxE8Q2nuvtepehFrNSCgv3LYfXrh2sUnZxtg8B8n/bfE+A++Ydz9zuODceOIE+MWccYE52LTi6S2gNndWMzbmcWyuuZn4lN4DPO/G5+TbKr0YH6N/GQ1k4xKuo6nVassJi5aTFks8qEpzjPcl65xG01u4Ew0p1E8ICZ+NTh1F/wVJ9CjvU0Q0beyEWfVRC7XIEXHm22edA9Ix3kCjqEubTFIE3J2iXsAvlzoEskazBV0oxXALl+v9zwVmRFKeixkoeOowzjQkgT8nAX9syxAqHAWTureaGVtffA93XPN4Bd6lPFcFQgsUfeU/Iv17Df456su0nImHp17HRvrpM1i3Zp62zic4kgXI+CE/e4qX7ML9LPozbj5OpMH6Az+CI8g2YMcqbzI1769fZCS0JWidQ+PhIrUWtXiopYh5k4qi+bsMIW55LtTLU2JRRIjh9a6uE+Bx1crxtfeNKvEQg+PhtdpgK19FhO3FoJqkZ/PThKgMwSV4gLyZI7F9iJEt45MWB+l1u/skMwTLbPV/YLYfql3aBgPObF6lWzfOXA3QFJt2eU5DlaRV74SlTJeItH5GblFjNt9SVmp1cRLh3kbqLxA2aDDvqv4t2qvk4p/jhq5Sc+IG+/s5irXIayg4qHFERg7S+NiCMVxTuG77JpXZ5h2x90MzL/jyVsNauZ5kAGgqClNsryjuDbHbDqXw2rhJS7f765FdAJjea8oYXQeVcQ5F+DFCKxEntVDS+4fKMRtPsIbHmA/SSCcn+Twv4X/BqOhCDC5CVpah6vopchipHRUiXA/2HpvESNFhPp4xrY3bAzWgGKRsjdFuFZ0EQ/PNj1OqDsWsphosgwEnBnVuT5e4vekUWngx76by4LXMZTM0iUiJLuoIW7EOExhWtVeLnvvORG8jOythyXatiCcvVORGPi9WTmtP gjRkzpgX 4gQTP2rvdHurx5FYiQpYTwexJLY+vcHBzd32XhKGz31JOrbqhbepkM6GtR/hgOJ7rVjMKrCZLnqIWuw/e+zxWSdajAWJmZSeWJdK00DrCtNul0LV1IxKHc3qHV3vf5rs3sSpxP0mgaIUjR9vS4U5gvxpBiR7QA0owt88+OuMzDXyFnxK3FdAOLf3jV74udrWvcFXBH8VOwcLdxpx1llw5UiHWgzZtKmNWs/Ee59boUBRtyQMo82HPtCCkS5fO/3YElqluq6XwCWyGLF0qYP1hfPkl1rCjvXJjmoSLXrKHYfdhuO0WRG6ZJ91mwzGp5Z8VJ9tattkPDM/uJuHJsOJV7pr5ocRXXw2tU2ou X-Bogosity: Ham, tests=bogofilter, spamicity=0.000337, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Em Tue, 14 Jan 2025 11:35:21 -0800 Dan Williams escreveu: > > There is no way to tell that the topology hasn't changed. > > For the reasons above, I don't think we care. Instead of trying to stop > > userspace reparing the wrong memory, make sure it is safe for it to do that. > > (The kernel is rarely in the business of preventing the slightly stupid) > > If the policy is "error records with SPA from the current boot can be > trusted" and "userspace requests outside of current boot error records > must only be submitted to known offline" then I think we are aligned. Surely userspace cannot infere if past errors on SPA are for the same DPA block, but it may still decide between soft/hard PPR based on different criteria adopted by the machine admins - or use instead memory sparing. So, yeah sanity checks at Kernel level to identify "trust" level based on having DPA data or not makes sense, but the final decision about the action should be taken on userspace. Thanks, Mauro