Linux driver-core infrastructure
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <ukleinek@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thierry Reding <thierry.reding@kernel.org>,
	 "Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	 Jonathan Hunter <jonathanh@nvidia.com>,
	driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
	 linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org,
	Thierry Reding <treding@nvidia.com>,
	 Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override
Date: Tue, 22 Sep 2026 15:17:26 +0200	[thread overview]
Message-ID: <arJ6s51FV4T9IK5w@monoceros> (raw)
In-Reply-To: <2026092227-marbling-untying-c1df@gregkh>

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

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.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2026-09-22 13:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 11:38 [PATCH 0/2] driver: core: Allow drivers to opt out of driver_override Thierry Reding
2026-09-22 11:38 ` [PATCH 1/2] " Thierry Reding
2026-09-22 12:13   ` Greg Kroah-Hartman
2026-09-22 12:49     ` Danilo Krummrich
2026-09-22 13:17     ` Uwe Kleine-König [this message]
2026-09-22 14:09       ` Thierry Reding
2026-09-25 17:21         ` Uwe Kleine-König
2026-09-22 11:38 ` [PATCH 2/2] pwm: tegra: Opt " Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arJ6s51FV4T9IK5w@monoceros \
    --to=ukleinek@kernel.org \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=richard@nod.at \
    --cc=thierry.reding@kernel.org \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox