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

[Thierry Reding <thierry.reding@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

On Tue, Sep 22, 2026 at 03:17:26PM +0200, Uwe Kleine-König wrote:
> 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@nvidia.com>
> > > 
> > > 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@baylibre.com>
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > ---
> > >  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@linuxfoundation.org/
> 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.

We could easily invert the logic in this patch to make this opt-in, but
it might be difficult to know exactly which ones want to opt-in, given
it's been enabled by default for a really long time.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]