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 7E1BEE77199 for ; Thu, 9 Jan 2025 16:20:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0E8A6B0092; Thu, 9 Jan 2025 11:20:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E96166B0093; Thu, 9 Jan 2025 11:20:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D367F6B0095; Thu, 9 Jan 2025 11:20:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 416086B0092 for ; Thu, 9 Jan 2025 11:20:01 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CCF8412021B for ; Thu, 9 Jan 2025 16:20:00 +0000 (UTC) X-FDA: 82988424960.12.301E544 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf25.hostedemail.com (Postfix) with ESMTP id A9ABDA0011 for ; Thu, 9 Jan 2025 16:19:58 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=RkLtBkYM; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736439599; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fFMiN1tnPtLjAxIUIMtgxfPtiWXSUncNXBiAsX2cXhA=; b=r9h6FtHNNaCieyhwXD5BTAp6MGBGFDI+IoxDehGkZ5d1Ar/A0KCbp8pbD6quvo3OFQTQgF +99BwSLu6S7p1ERNTq2TePsmy2QntS739y8V0+rlMwuQFrpllJK7qgDTUiwCsUU8eEAK2x xLy58uffhysIpmVPTGQ6EJsErvuw3FI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=RkLtBkYM; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736439599; a=rsa-sha256; cv=none; b=q5hxwCt97CiNWa7WuTC9KuYkeTeXX8z5zDeZJPwTTwS+jDRMgduOLaimuWC4niQvPqkVA8 xi9evQP35yzJNG17SMeuLXRytYpV/FxoMYMmZ6UGLa0nQOHaqy947xu3iy9i5w+sImJMjy 1VfByHVlYTZAC343yG2PnllBWUelXI8= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 81E3640E028B; Thu, 9 Jan 2025 16:19:55 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E1yBSN-FQfqE; Thu, 9 Jan 2025 16:19:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1736439592; bh=fFMiN1tnPtLjAxIUIMtgxfPtiWXSUncNXBiAsX2cXhA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RkLtBkYM247YXiypz7ani0G2iHbSTtmaY2KyE2aF9VvsMadiQV5AhuX2E34pqBHhV ogPs7NzUGg+pI8rJe4BQHy3rnYZ0uOWL3l8yujemXz35nkz/MguEOjSPoJC07/Z0ww ok7p0nF25Vod1mbj5jTqacOL80lD7zcxhE5MDiBGe86zlWLCXey+lKrLcAoGoeJsuD 1ledtXr2rKqxE4BMbgkipVCWJRa3UPyRhggim3YuSmx6GKHpy1LhjDCO4pBFG7mstc Bygp+ng0vK8GrvG3AxmIP4Zsy/kC5LzBvcfuWtsBgjQe8rhejs92ssWjLY1R82rz1P hcqsT4bXn+mGAJTxbteqfxFDKS6xfbTd0WRBlzX4vogE1sIlG/XEOllSRKslkrimVJ DrsrKERUHHtgIuv3gifCWb/hyCXon+LdiB6MHu6eMNQHE++NvI0nwN3HALJ6JAaBvX d1axMiFpjd3jMznL6Yej1xye0EgIRtfksEAUez6px8HJxkFaucJouQuFJpJ1zoLNDo VDCX1vompoUUDQsb7y9ht2CszmlGDiVW2heif5cEGYEarimqIM3ghzy+BUurEEiRMy /3FVEIvABOkiC7A+dWJo2ogZYnQeER6dD/pFooXD5nkauRZkqWVSj9WlHMPVxdWUJd 2xbMTmR2yQKnMK3fMjfLukbA= Received: from zn.tnic (p200300ea971F933C329c23FfFeA6a903.dip0.t-ipconnect.de [IPv6:2003:ea:971f:933c:329c:23ff:fea6:a903]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 994F140E01F9; Thu, 9 Jan 2025 16:19:08 +0000 (UTC) Date: Thu, 9 Jan 2025 17:19:02 +0100 From: Borislav Petkov To: Jonathan Cameron Cc: 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" , "dan.j.williams@intel.com" , "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: <20250109161902.GDZ3_29rH-sQMV4n0N@fat_crate.local> References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-5-shiju.jose@huawei.com> <20250109091915.GAZ3-Uk3rkuh38cQyy@fat_crate.local> <3b2d4275d1d24dbeacee0f192ac4d69b@huawei.com> <20250109123222.GBZ3_B1g3Esgu1-MPi@fat_crate.local> <20250109142433.00004ea7@huawei.com> <20250109151854.GCZ3_o3rf6S24qUbtB@fat_crate.local> <20250109160159.00002add@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250109160159.00002add@huawei.com> X-Rspamd-Server: rspam05 X-Stat-Signature: xa9nxwc7gu3skoo6ucigbsqgdnws8c17 X-Rspamd-Queue-Id: A9ABDA0011 X-Rspam-User: X-HE-Tag: 1736439598-244847 X-HE-Meta: U2FsdGVkX18xKtKzwyg7Py/GyuqQlaVHvc9llUHzJT2+EAdFrI9BMzXo3AKJY+2/PgUaVf5cusgv6QhpC+DUtf4SDlszEcy4jGg1ss4rX4KS84pA08gkzPM1yO6c8JV7Hr1ACWNnVM6RQNujRKNTcaRvoWhp0Pmu4Rmuk26H0K6rojRV5EMmkj196/ZiSL1I9JY5IFae0Kae2oDpSp8v5KsbwH6K2W9Czr9xLc2hH2bE+5Te8C2unUj1rNsmgoyvpHzE6vaCjitFWLxwBdUiCA+vE4Rj6UTv580EbLpAdXlWfjIEno5eFaW/1VxL6Q1Sd66qj5htdkzRNo38aB6/KUx3MZkWTSWJMaYGCylqhyapFEVy4AXwQSKzIw2GjS1xUOhELnaVW+xAj4/WmZeUilJLNbGNc4m7Mk+7yVQNXRZ9NpQ+O8cVqrJHxtiU67UvSYoU1AozaioI1+qEc18zCGwZ9iluRv44URrkxUtIIdyjvtce73AV3GjiTjBiPykXlfiiUCBxZ0X1hjR1I524jRvgn1HKxFMZvIEBt/DX+NaYgCImUcHXFZdJ5TOphePxtZRxlqqd2NRJllZ4mkMuoAsCR2Chbo37kQK/3bk1ZIDKP+5TUHITxzuSHQPdB/APBhb6e5RCydjkn3AiFerKLYK+8OYCTxwg+VS1YURTlbQ7KbrtW+5ASi7ZVmYgr4SPOa465I4x0OaGGka7iCfhxIfuagw6BQElhvgUG2af5JRcXtKp6heBVZqMo/tjGjXpB1eAdgdKy9/lhaLpeDkt8Bo1Ih1hwRCEj5zQhCzPjM4uny/Kv+NKUKKvqk1cZNPxAU/avgomtvZuFRaj39XE/Scz3fMbedei8A/iEiwIJXKwj9q8qAIV7UJbBc24w3nGO4t+WXUGDYdGEDrs35UAaggOhKz5UqOC4CaNUtqVdp8bE50YR8Bn7P/kAmVKxXoDc/1FE9D8DSiYDFtHnUb 9q8ai8nj LTioLU5R/jpSzufuNTb6UIJ5fLb2Yo5djMYpj1sahARoPCh7dgF5UrwxmjE4J9/3a9ccpjpsF0cyyzasSOdZzCRQUV4TEAsqBayqy7VwHgg/W6yM1L019zAyCTzi3awEhTDLpFlqh8yv5u67DDOgUqtry5mqICHHzy93rWWH47Nf0EKWM1gnuHkhdEc2b8kbAgymBjVAB65szk0pW6kPZe3NpNqOo1zbEGKNXaopc32yCmoMpNGJR0+6WRvSzJy44ROppbKv7faQY0KwxI0QXMrzUtZH4eLeGUeD7Jo/y0LEQiiSQO/oDEDGZPXXejKHQZDWUEdStAgmzSVtzND2w+EaJMXsi/SM8ByFRoqD7NFIKFww= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 09, 2025 at 04:01:59PM +0000, Jonathan Cameron wrote: > Ok. To me the fact it's not a single write was relevant. Seems not > in your mental model of how this works. For me a single write > that you cannot query back is fine, setting lots of parameters and > being unable to query any of them less so. I guess you disagree. Why can't you query it back? grep -r . /sysfs/dir/ All files' values have been previously set and should still be there on a read, I'd strongly hope. Your ->read routines should give the values back. > In interests of progress I'm not going to argue further. No one is > going to use this interface by hand anyway so the lost of useability > I'm seeing doesn't matter a lot. I had the suspicion that this user interface is not really going to be used by a user but by a tool. But then if you don't have a tool, you're lost. This is one of the reasons why you can control ftrace directly on the shell too - without a tool. This is very useful in certain cases where you cannot run some userspace tools. > In at least the CXL case I'm fairly sure most of them are not discoverable. > Until you see errors you have no idea what the memory topology is. Ok. > For that you'd need to have a path to read back what happened. So how is this scrubbing going to work? You get an error, you parse it for all the attributes and you go and write those attributes into the scrub interface and it starts scrubbing? But then why do you even need the interface at all? Why can't the kernel automatically collect all those attributes and start the scrubbing automatically - no need for any user interaction...? So why do you *actually* even need user interaction here and why can't the kernel be smart enough to start the scrub automatically? > Ok. Then can we just drop the range discoverability entirely or we go with > your suggestion and do not support read back of what has been > requested but instead have the reads return a range if known or "" / > return -EONOTSUPP if simply not known? Probably. > I can live with that though to me we are heading in the direction of > a less intuitive interface to save a small number of additional files. This is not the point. I already alluded to this earlier - we're talking about a user visible interface which, once it goes out, it is cast in stone forever. So those files better have a good reason to exist... And if we're not sure yet, we can upstream only those which are fine now and then continue discussing the rest. HTH. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette