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 --]
next prev 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