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 7D502C25B4F for ; Thu, 9 May 2024 09:19:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04BB16B0083; Thu, 9 May 2024 05:19:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3B606B0088; Thu, 9 May 2024 05:19:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E03596B008A; Thu, 9 May 2024 05:19:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C112B6B0083 for ; Thu, 9 May 2024 05:19:49 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 64ECE812EF for ; Thu, 9 May 2024 09:19:49 +0000 (UTC) X-FDA: 82098310098.14.6CAE398 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf12.hostedemail.com (Postfix) with ESMTP id CCB0C40009 for ; Thu, 9 May 2024 09:19:46 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715246387; 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; bh=CQ/IzvN8Lqpv/LIKV7Wxy5hbAQq04U/55Ih4K/YBORQ=; b=WG5m2YMBc2yQ2IFjUTII8ceF1kq9Ucx31/bgow0svu7A1iq4Fp3h5mp5sjVyAVvLEjiUwE LbMhkCrUle09bDzg+nhMB4zPi0vCBZaLeAaacr0nlrOdt7TuozOPV9iQNu3FDmvKf6qI+Z k2Lwz6b5+fBx0n3LcUdCI4JNUaSPljE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715246387; a=rsa-sha256; cv=none; b=0UauU3RrvMTdIiKIzguSJq8jvpDtGM5tFO4eLJr9aDHGT42xTr1NZhVr7Qhy4iqAssxZYh dBWGiQI/4MGNlZnmN1mH/h9D9VMQmC1GfLsyvHifiBTIZnwUUgZY+JntmKiEZy84Gm/okl FsCoMon6m5qPMg+g0miFgcE2Ut5ylzM= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VZmbq6JsKz6J9rQ; Thu, 9 May 2024 17:16:39 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id CF873140C98; Thu, 9 May 2024 17:19:41 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 9 May 2024 10:19:40 +0100 Date: Thu, 9 May 2024 10:19:39 +0100 From: Jonathan Cameron To: Borislav Petkov CC: Shiju Jose , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.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" , "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" , "Rafael J. Wysocki" , Jean Delvare , Guenter Roeck , Dmitry Torokhov Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem Message-ID: <20240509101939.0000263a@Huawei.com> In-Reply-To: <20240508192546.GHZjvRuvtu0XSJbkmz@fat_crate.local> References: <20240419164720.1765-1-shiju.jose@huawei.com> <20240419164720.1765-2-shiju.jose@huawei.com> <20240425101542.GAZiotThrq7bOE9Ieb@fat_crate.local> <63fdbe26b51f4b7c859bfb30287c8673@huawei.com> <20240506103014.GHZjixNhhFkgkMhDg_@fat_crate.local> <20240508172002.GGZju0QvNfjB7Xm6qL@fat_crate.local> <4ceb38897d854cc095fca1220d49a4d2@huawei.com> <20240508192546.GHZjvRuvtu0XSJbkmz@fat_crate.local> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100004.china.huawei.com (7.191.162.219) To lhrpeml500005.china.huawei.com (7.191.163.240) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CCB0C40009 X-Stat-Signature: bfbomez9q7st39bx8xzngqnzowr7oed4 X-Rspam-User: X-HE-Tag: 1715246386-26464 X-HE-Meta: U2FsdGVkX18wlTtcIMeE2joIe0Tw1fkFfAU7mkcVVAsfNtt4kSW/DCyb1O0D9LfN8/HBQzXr3jX1VRjsdan5798Us+zh3qzo+p8sEA+Qp2vMuERSus+kcZi4YVkKJYC5+j1amUWzCrVtjLas0enjx1r4zeqtc0w4XYbJi18YFX9oeP4jrZUFg5KFH2KtRi3Z9vIEJBzu6zVIRsvcSEBNeF6uNTz0+gjNCaFsA9TQiDtyxrEUm+QXldra2C7NKJ6zMmbXQu/FzfkZfgAamSfS/+z9bBFHGo92E5J1F+38VwH4Bo5Cf5NZK98SJ2pYjk36h9C6zC2dKshELFzYhwpJZ1T8j4HEzJRorchM/QN+HQKI2nIbo8um9c1Fc9x98OS1zb3U6HJS0ObUAK7dl9OjrrU95dsuzb/FY2JgidvXNq3HmfEvTo3jqcVwtdKAMTimaHQsm4bKJ+7ATA+21dKAlB89gJiXeM9wEo/11U4zet7l4vPu40L5icl52/PT2BDbtM46RhZF+voM6mAfG97NBRYIT9sQ0oNj3Deauyf+i90h3g9he7OBhxhjt2ftsCwCuQuJlS61dTeS4zaRfPQ8Na9DiUXd+NJ68TZPtmDY1lJsNPBdFZnGWHQQc5S/heWlGt5SaQT42k0aMEyESrBg9UhKaytWRfz6ovT7T1ZktdqzfUNpGWRVlSUw4ZS1ddaJL0t90VLba3hY1eFd/Ly1kPJNCnm4Op4HnNHuTk5l7cIHif5qvnfX5rF7JEgxtmTT+Jd8HZFUA9XXO0QVeYXebJmF53SLgWmYmRJrIF5ZfOO99nZvTWm6dAAw5Y+WSfB06QuIuMDqG4M/ljEFG5AEkCbtS6bbn8ST+cDmlHJeVkyGU/GhiyE1yawsGUhYfzjSuhQcyPPatWZPbubnFFmDuSgy5SeNSIa2OOUmkwcz05XDoxmVvKITDuKV4AOm3MH9XPL3lWyZAgg1VwTFOAq bkVWP3BT 6aU/HTkTWPS4A6Ct8iVX1w1rGGY0QVS39tdVxyKegrza5L5AvCMocoBgYQ41cY6tYjzGjXO7W6IT2kT2DaXKYtoZFsz/P1DNSqAEw+v+vXRFon2VXrlLRJD/GmszDpHE0Ii46kWRH3mqV3hfJZkDAZXtkpLP6acHE7Ep2Bh/iNlLvvX50c1RIKjpurB/iabL57I8gwEVKpzZPU+P8YkOkbfOY8k8LpKIYbwswXcwokPD8nZfuQx1U3Jsu8fPeajy06mtu/DCF+Wn2/kHao0Zmuje3olkQB48CncbXy/War0MZ2VW9Z3ZoPhi8IoY+TJr+66i3 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 Wed, 8 May 2024 21:25:46 +0200 Borislav Petkov wrote: > On Wed, May 08, 2024 at 05:44:03PM +0000, Shiju Jose wrote: > > I mean scrub subsystem module is not loaded and initialzed until > > a dependent device module is loaded and a device does not get > > registered with the scrub subsystem on a machine which doesn't have > > the corresponding scrub features. > > Stop this rambling blabla please. This should *not* happen: > > # insmod ./memory_scrub.ko > # echo $? > 0 > # lsmod > Module Size Used by > memory_scrub 12288 0 > > This is on a silly guest which has none of those dependent devices crap. > > Your scrub module should load only on a machine which has the hardware > - not just for fun and on anything. Fundamental question seems to be: Why should it not load? Shiju and I think it should, you think it shouldn't. Note this is only if someone deliberately ignores all the infrastructure intended to make sure only relevant modules probe and modprobe / insmod by hand. +CC some driver core folk and a few other subsystem maintainers who have subsystems doing the same as this one. Summary I think is: Borislav is asking for this new scrub subsystem core module to not successfully probe and call class_register() if it is manually inserted and there is no hardware on the particular system. It's a standard class type situation with core driver providing consistent ABI and /sys/class/ras/ with drivers hanging off various buses (currently ACPI and CXL) registering with that class. Many subsystem core drivers will probe and create subsystem specific sysfs directories on on systems that don't have any hardware needing drivers from that subsystem (if someone manually inserts them rather than relying on automatic module dependency handling.) I don't see why this class driver should be different and have to jump through hoops to satisfy this requirement. A quick look for callers of class_register() in their init functions found plenty of precedence. Many of the cases that don't do this are single use - i.e. class that only ever has one driver. There are even more if we take sysfs buses into account. (edac and IIO for example) A few examples of same handling of class registration. - input - that registers a lot more on class init, but sysfs class registration is in there. - hwmon - other than some quirk setup same as the scrub driver. Other than embedded systems with a custom build and kernel developers, who actually probes modules manually? Mostly people rely on modalias of the client drivers and them pulling in their dependencies. Modules are pretty pointless if you probe all the ones you've built whether or not the hardware is present. It would of course be easy to do the class_register() on first driver use but I'm not seeing a lot of precedence + the scrub class module would still insmod successfully. I think preventing load would be messy and complex at best. Jonathan