Re: [PATCH v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
flat view
From: "Danilo Krummrich" <dakr@kernel.org>
Date: 2026-09-27 09:55:43
Also in:
driver-core, lkml
On Sun Sep 27, 2026 at 10:03 AM CEST, Uwe Kleine-König wrote:
Commit fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when
userspace manually messes with devices and drivers") introduced a taint
for usage of bind/unbind sysfs files that manually trigger driver probe
and remove respectively.
For drivers that do their resource management correctly (which is also
needed for module unloading) bind and unbind for matching devices are
not critical operations. The thing that makes bind and unbind unsafe is
that drivers can be forced on devices that originally don't match using
driver_override. The result is that e.g. of_device_get_match_data()
returns NULL despite all .of_match_table entries having a non-NULL
.driver_data member which yields a NULL pointer exception for several
drivers. And given that after setting a driver_override a manual bind is
only one way a driver can be bound to an unexpected device, a separate
taint for such an override is justified.
Reviewed-by: Bradley Morgan <redacted>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Uwe Kleine-König <redacted>Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/ (local)
quoted hunk ↗ jump to hunk
diff --git a/drivers/base/bus.c b/drivers/base/bus.c index c51ad96d4de4..7d5dc016a457 100644 --- a/drivers/base/bus.c +++ b/drivers/base/bus.c@@ -513,6 +513,7 @@ static ssize_t driver_override_store(struct device *dev, { int ret; + add_taint_module(NULL, TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK); ret = __device_set_driver_override(dev, buf, count);
There are buses (such as SPI) which unfortunately have to call __device_set_driver_override() directly. I think it would be better to move the taint into __device_set_driver_override() and properly document the purpose of __device_set_driver_override(). It only exists as SPI and AP are a bit special; both print "\n" when driver_override is not set, whereas all other buses (and thus the driver-core) produce "(null)\n" in this case. I.e. it should never get any new users. Thanks, Danilo