Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override

[Uwe Kleine-König]

Hello Greg,

On Tue, Sep 22, 2026 at 02:13:58PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2026 at 01:38:28PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@xxxxxxxxxx>
> > 
> > Some drivers rely on device data obtained through device ID matching and
> > will not work otherwise. Some such drivers don't check for the validity
> > of the device data because it is never NULL when the device is matched
> > against the device ID table.
> > 
> > However, Uwe recently pointed out that drivers always need to check this
> > device data because any device can be forced to bind against a driver if
> > their driver_override sysfs attribute is set and the driver rebound. Any
> > such device will now not have device data from a device ID match table
> > and may crash.
> > 
> > Add a flag that allows drivers to opt out of the override mechanism when
> > it doesn't make sense. This allows us to deal with these situations in
> > the core rather than sprinkle checks throughout all of these drivers to
> > check for validity of the device data.
> > 
> > Cc: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx>
> > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
> > ---
> >  include/linux/device.h        | 12 +++++++++---
> >  include/linux/device/driver.h | 12 ++++++++++++
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 90cdd77458bb..45c23cc5efa8 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -899,14 +899,20 @@ static inline bool device_has_driver_override(struct device *dev)
> >   *
> >   * Returns > 0 if a driver override is set and matches the given driver, 0 if a
> >   * driver override is set but does not match, or < 0 if a driver override is not
> > - * set at all.
> > + * set at all or the driver opts out of the override mechanism.
> 
> What's wrong with just not allowing bind/unbind at all?  Why would you
> want that, but NOT the driver_override file?

bind/unbind and driver_override are two very different operations. The
first is something that should generally work and I consider it a safe
operation. The practical use includes reloading drivers that hang and
also switching operational devices on a devboard that cannot be used at
the same time due to pinctrl conflicts or different clk needs.

driver_override is a foot gun that allows to bind unsuspecting drivers
on foreign devices and thus make e.g. of_device_get_match_data() return
NULL for a driver that assumes that cannot happen because all
of_device_id entries have a non-NULL .driver_data yielding null pointer
exceptions.

See also the feedback you got on
https://lore.kernel.org/all/20260914-bind_taint-v4-0-eadf8a090903@xxxxxxxxxxxxxxxxxxx/
where (apart from me) Danilo Krummrich argued that unbind/bind should be
considered safe compared to driver_override and also our conversation in
#kernelnewbies where Richard Weinberger concurred to that.

Having said that I think there is only a handful of drivers that are
actually supposed to work when used in a driver override (vfio stuff,
spidev and i2c-dev come to mind), so I'd prefer that drivers opt-in
instead of opt-out. Otherwise we yet another flag that drivers should
set in general but don't because driver authors are not aware[1]. The
few drivers that rely on driver overriding should be identified quickly,
and if we miss one that doesn't result in a way to make the kernel oops.

Also note that setting .suppress_bind_attrs on a driver doesn't prevent
driver_overriding. After you point a device to a different driver you
might not make it bind via sysfs immediately, but that might happen at a
later point. (I'm not sure, but maybe it's enough to plug in a USB
thumbdrive?)

Best regards
Uwe

[1] Do you know about struct device_driver::probe_type =
    PROBE_PREFER_ASYNCHRONOUS?

Attachment: signature.asc
Description: PGP signature