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 4CF3BC25B10 for ; Fri, 10 May 2024 09:26:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D604B6B00A6; Fri, 10 May 2024 05:26:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0F8A6B00A7; Fri, 10 May 2024 05:26:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB1046B00A8; Fri, 10 May 2024 05:26:16 -0400 (EDT) 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 9D9536B00A6 for ; Fri, 10 May 2024 05:26:16 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 460E5C05CA for ; Fri, 10 May 2024 09:26:16 +0000 (UTC) X-FDA: 82101955152.21.EE314BA Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf19.hostedemail.com (Postfix) with ESMTP id ED7E41A001D for ; Fri, 10 May 2024 09:26:13 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=XUfzHMep; spf=pass (imf19.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=1715333174; 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=fRAsiqdaxYNLWRPjqSgsM/ZnfQQhG+p8NwrR51D23nw=; b=dOZ+7o9MafNgQ1ZrVR3POUadiuv5Bx37czacCRhouHfgUymwYqGKOcGCUi/BASxnYv/B4y UOCw9PhIE9KjfYffsBkB5if/tEd/FsjIl6n3FpfZVtoGxlPNA2O25ft1kTJuTubSpB+Ik5 N55dQq+bKcrAK9RqJZ7CRBF9ve9ciks= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715333174; a=rsa-sha256; cv=none; b=OqCVcMn4roTexI8hjA8JetlsOZnzqDYMqK3tvbdTxiJmVaWPPPwAwy/bh2m4Jc+Mjlhchx 5H/4loSH85w+gX56a3o8oRo+1Chbgn/OBuHo2BNf5aIfQBPN8AI9ADy52I/UapPwRJbqfG 6uJvFZeEH1if6z5GT5SYI2uyMrQKOuU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=XUfzHMep; spf=pass (imf19.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 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 17A2440E0249; Fri, 10 May 2024 09:26:10 +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 plVXWEu6CSsG; Fri, 10 May 2024 09:26:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1715333163; bh=fRAsiqdaxYNLWRPjqSgsM/ZnfQQhG+p8NwrR51D23nw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XUfzHMepSn4/+ARY812zuUTZb37qycJWK1yUQ/J5b0dM1vo/H4JxUPvCeFPJtXZ92 4tDsOc1Gxve7TVkNl8IITGIAZTp3mCJ+0esUpdjY5h3ZfLe2exvjxxd9KxEUwEIfIb UtyEIUDSTywR16SF8+u/T8bO8Z4r3V8zHVf0NfIqKwwx3XgMKSAYHkHSVASdFtQSd0 v2m3vSCRS/j7npFX/QRO9qzkWpdh6ywBiQ5Q6qnn323/AWpecrLBHX/BBAYEM0bXcE 8CrYjb/Xlu5pBV7KJmCCI1D9zISrgytBG+8w0KE+QGfp+8Bx8F2xbusnHqF6+8ptB3 ppUjQgSuH0QGyOcHpP7z9ykO7LWPIJkALa5s+08UjIB+WZIIdRIfzBdnJqeg9W+gjP 9gx1i5OeCuBTPDZ39+2l4dJCMFm/p6p2D/d87x8KYrLjcGeHx+hf+oz4ECjUIX7XM7 20wxMOHyLhstOSOvcDEBUIirXRXu5rv8UdTa+it96/mfIfoNpzXQ0Bzs4sa4ZgZOSv j7oRwPSN53LFchyK9MyjIha7+u6ObleFB20Y0TM+jvFCR9p7FyoyyebUyFps7NWjDr PjRYNWCqDrNjuQ3/QkiVrNTKVI/qx2Eo5vghzBSGYvaeFF7oyFmp/V6eQZVyGmjRNz VFI/97BiGc+9OZSKaGWZj0dA= Received: from zn.tnic (pd953020b.dip0.t-ipconnect.de [217.83.2.11]) (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 AE34040E0187; Fri, 10 May 2024 09:25:16 +0000 (UTC) Date: Fri, 10 May 2024 11:25:11 +0200 From: Borislav Petkov To: Dan Williams Cc: Jonathan Cameron , Shiju Jose , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "dave@stgolabs.net" , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "tony.luck@intel.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "mike.malvestuto@intel.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm , Greg Kroah-Hartman , Jean Delvare , Guenter Roeck , Dmitry Torokhov Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem Message-ID: <20240510092511.GBZj3n9ye_BCSepFZy@fat_crate.local> References: <20240508172002.GGZju0QvNfjB7Xm6qL@fat_crate.local> <4ceb38897d854cc095fca1220d49a4d2@huawei.com> <20240508192546.GHZjvRuvtu0XSJbkmz@fat_crate.local> <20240509101939.0000263a@Huawei.com> <20240509200306.GAZj0r-h5Tnc0ecIOz@fat_crate.local> <663d3e58a0f73_1c0a1929487@dwillia2-xfh.jf.intel.com.notmuch> <20240509215147.GBZj1Fc06Ieg8EQfnR@fat_crate.local> <663d55515a2d9_db82d2941e@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <663d55515a2d9_db82d2941e@dwillia2-xfh.jf.intel.com.notmuch> X-Rspam-User: X-Stat-Signature: mp7x48xdp8pko7ffpnozfp3ozz9m1r1i X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: ED7E41A001D X-HE-Tag: 1715333173-985700 X-HE-Meta: U2FsdGVkX18vi5YBuqa5HAep5MemO/PqkXhq4d874mId4NevHbacr8MC3YENzJZkRk9pIKyMpmz5Su8APdhmPqTTgR5K9G5KTE/0pccfIHypHS0dXFVpm8nf8ddRZvFHQafqTThEV9aGFEUf/ZsveaAC5olwTKAKeKA4WTubaR0T2n0DGi6SzuHmmKfitQIeGzc27Wgf2T67UlMCOYMlLMAXUuKH19Ijir8jbTjYL/AVyoGc/jG5xvjkcxLF8kZZr3actGViYDsL8gD0svfOhgk/Yue/9f2Wx2O11s6OkoRpmwxx6jMyvDzjill6V175ucOS0m0m/LrFeCGKuuawTy91RCyZW/TFVMNozxjmnWlHBgbkBR9WEORItUpH8lQrqxnumNBjcz/8XQobGajfP4mfcOSwXUGbLQiIDWFvTTENyNo0xvTvGCiz91I6lInk98KfUobdRbvJawTswkUwooFHdusZ1LZJ7bBkMrFN4ggFsHH+N1y8LWIEe3gMUKfmZ9WTSbcI4ajEOh61J903rjn0HqoqAyWLb623wKLw7lJxywqw8K/NGRnivYyjHLb66OhtvOlt/g+nvnHJXEGF8ztiHsz8UiyxxYy9z9IdjL3kWgQp7SAOnWgaEgwu6cWSnJKd5s+ufdqX1kUN3Hvsd7j91z76sDyjhRPlV0qlEosI+BXs/k9Eb2F/d/29XIq35EyDuEwN22EKWY93ikqQjVlCFZiEsVz0M6nfoRhx3gIAQi1gaUIHaQ5SlYz2r3/U463FTo/uO0sEW8yivTrf+no/72xK5YB0PX+4ZnuReTNUOs6SvAZYQQ8rfejNde7h0gqTdH2rcEjQvexzYfGGwLovWlak2AH8PUh799W+uDSybNBtJSF9jTekjExNAnzgVEYRb4Asb6RnzYcFqupxlIUfRvgtyycoCqn0xOUBlznn7/wt07FkwHaomcBZ1gQYbAcAauLRL9b133fvPNw e5we3PW1 rIeh/SWGtbjALPfEzL0Mmta5vS1R+Qhm+2I5TVtdL3h5susm/Xg71gKL/JUvXtbtuc6fg5hJbkc5+iyYALEeV8lHoWVaLlwyeUoE8CPdJAn8Fqk10QVEsS2PKJjDYQY4yNB2xT8WD5649kgRdhixT+rXWQV7HESLm99XQgLOdbRPd1logOAYzWXtb67tVZBqDRE99bfk5HhqMacjtcAjBAo2zVet1ax1FgiWyL4qG7gqIanlOKXlgTp53PzQZWP5U+83x0b4FolfrTITLR6903256EMGIqb95Y7Vgocmr8tAQe7dvMgPRCCpkcyubr2WKxGv7 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: On Thu, May 09, 2024 at 03:59:29PM -0700, Dan Williams wrote: > No, at a minimum that's a layering violation. This is a generic library > facility that should not care if it is being called for a CXL device or > an ACPI device. Really? Because this looks like creating a subsystem for those two newfangled scrubbing functionalities which will be present in CXL devices and by that ACPI RAS2 thing. Because we have a *lot* of hw scrubbing functionality already. Just do: git grep "scrub" Some of it controls hw scrubbing. If this is a generic facility, does this mean that all those older scrubbers should be converted to it? Or is this thing going to support only new stuff? I.e., we want to disable our scrubbers when doing performance-sensitive workloads and reenable them after that but we don't care about old systems? And all that other bla about controlling scrubbers from userspace. So which is it? > I think it works for x86 drivers because the functionality in those > modules is wholly contained within that one module. This scrub module is > a service library for other modules. Well, you have that thing in EDAC. edac_core.ko is that service module and the chipset-specific drivers - at least on x86 - use a match_id to load only on the systems they should load on. If I had a BIOS table which had "EDAC" in it, I won't load edac_core.ko either but there isn't one. > It is functionally the wrong place to do the check. When module_init() > fails it causes not only the current module to be unloaded but any > dependent modules will also fail to load. See above. I'm under the assumption that this is using two methods to detect scrubbing functionality. > Let's take an example of the CXL driver wanting to register with this > scrub interface to support the capability that *might* be available on > some CXL devices. The cxl_pci.ko module, that houses cxl_pci_driver, > grows a call to scrub_device_register(). That scrub_device_register() > call is statically present in cxl_pci.ko so that when cxl_pci.ko loads > symbol resolution requires scrub.ko to load. > > Neither of those modules (cxl_pci.ko or scrub.ko) load automatically. > Either udev loads cxl_pci.ko because it sees a device that matches > cxl_mem_pci_tbl, or the user manually insmods those modules because they > think they know better. No memory wasted unless the user explicitly asks > for memory to be wasted. The scrub.ko goes and asks the system: "Do you have a CXL device with scrubbing functionality?" "Yes: load." "No: ok, won't." > If no CXL devices in the system have scrub capabilities, great, then > scrub_device_register() will never be called. > > Now, if memory_scrub_control_init() did its own awkward and redundant > CXL scan, and fails with "no CXL scrub capable devices found" it would > not only block scrub.ko from loading, but also cxl_pci.ko since > cxl_pci.ko needs to resolve that symbol to load. Why would it fail the scan? Isn't this fancy GET_SUPPORTED_FEATURES command giving you all info you need? > I would not say "no" to a generic facility that patches out module > dependencies until the first call, just not sure the return on > investment would be worth it. >From the discussion so far yeah, I think you're right, it is not worth the effort. > Lastly I think drivers based on ACPI tables are awkward. They really > need to have an ACPI device to attach so that typical automatic Linux > module loading machinery can be used. The fact this function is a > subsys_initcall() is a red-flag since nothing should be depending on the > load order of a little driver to control scrub parameters. Yeah, it is becoming a mess before it has even started. So I don't mind if such drivers get loaded as long as doing this is the best we can do given the situation. What gets me up the palms, as they say in .de, is "just because" and "look, the others do it too." Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette