Message-ID: <20240509101939.0000263a@Huawei.com>
Date: Thu, 9 May 2024 10:19:39 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Borislav Petkov <bp@...en8.de>
CC: Shiju Jose <shiju.jose@...wei.com>, "linux-cxl@...r.kernel.org"
	<linux-cxl@...r.kernel.org>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>, "dave@...olabs.net"
	<dave@...olabs.net>, "dave.jiang@...el.com" <dave.jiang@...el.com>,
	"alison.schofield@...el.com" <alison.schofield@...el.com>,
	"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>, "ira.weiny@...el.com"
	<ira.weiny@...el.com>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "david@...hat.com" <david@...hat.com>,
	"Vilas.Sridharan@....com" <Vilas.Sridharan@....com>, "leo.duran@....com"
	<leo.duran@....com>, "Yazen.Ghannam@....com" <Yazen.Ghannam@....com>,
	"rientjes@...gle.com" <rientjes@...gle.com>, "jiaqiyan@...gle.com"
	<jiaqiyan@...gle.com>, "tony.luck@...el.com" <tony.luck@...el.com>,
	"Jon.Grimm@....com" <Jon.Grimm@....com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "rafael@...nel.org" <rafael@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>, "naoya.horiguchi@....com"
	<naoya.horiguchi@....com>, "james.morse@....com" <james.morse@....com>,
	"jthoughton@...gle.com" <jthoughton@...gle.com>, "somasundaram.a@....com"
	<somasundaram.a@....com>, "erdemaktas@...gle.com" <erdemaktas@...gle.com>,
	"pgonda@...gle.com" <pgonda@...gle.com>, "duenwen@...gle.com"
	<duenwen@...gle.com>, "mike.malvestuto@...el.com"
	<mike.malvestuto@...el.com>, "gthelen@...gle.com" <gthelen@...gle.com>,
	"wschwartz@...erecomputing.com" <wschwartz@...erecomputing.com>,
	"dferguson@...erecomputing.com" <dferguson@...erecomputing.com>,
	"wbs@...amperecomputing.com" <wbs@...amperecomputing.com>,
	"nifan.cxl@...il.com" <nifan.cxl@...il.com>, tanxiaofei
	<tanxiaofei@...wei.com>, "Zengtao (B)" <prime.zeng@...ilicon.com>,
	"kangkang.shen@...urewei.com" <kangkang.shen@...urewei.com>, wanghuiqiang
	<wanghuiqiang@...wei.com>, Linuxarm <linuxarm@...wei.com>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
	<rafael@...nel.org>, Jean Delvare <jdelvare@...e.com>, Guenter Roeck
	<linux@...ck-us.net>, Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem

On Wed, 8 May 2024 21:25:46 +0200
Borislav Petkov <bp@...en8.de> 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

Powered by blists - more mailing lists