Re: [PATCH v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sun, Sep 27, 2026 at 11:55:39AM +0200, Danilo Krummrich wrote:
> 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 <brads@mainlining.org>
> > Reviewed-by: Armin Wolf <W_Armin@gmx.de>
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> 
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/
> 
> > 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.

Huh?  That feels wrong, can't we fix s390 and spi instead?  Ok, maybe
not s390, but why is spi doing that?

thanks,

greg k-h