From: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johan Hovold <johan@kernel.org>,
Aaron Tomlin <atomlin@atomlin.com>,
Bradley Morgan <brads@mainlining.org>,
Thierry Reding <thierry.reding@kernel.org>,
David Lechner <dlechner@baylibre.com>,
Armin Wolf <W_Armin@gmx.de>,
linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
Date: Tue, 29 Sep 2026 07:53:23 +0200 [thread overview]
Message-ID: <artRKXU0jygdcxx3@monoceros> (raw)
In-Reply-To: <DLR4AMFM8QZ2.36R6G0LD9D53Q@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]
On Mon, Sep 28, 2026 at 07:15:12PM +0200, Danilo Krummrich wrote:
> On Mon Sep 28, 2026 at 6:46 PM CEST, Uwe Kleine-König wrote:
> > Note that different to Danilo's suggestion I don't differentiate between
> > driver_overrides setup in userspace and those setup in kernel space.
> > IMHO all are bad and there are alternatives for the legitimate cases.
>
> I agree that the implementation - i.e. (ab)using driver override - the affected
> subsystems have chosen is wrong.
>
> But, there is a difference between picking the wrong implementation and being
> semantically wrong to a point that we need to taint the kernel.
>
> So, yes this should be cleaned up, but we should not taint the kernel for
> otherwise correct code. Otherwise we could as well taint the kernel for every
> other abuse of an API.
My position on that is: Do the global change now and help the subsystems
to clean up the mess. In my experice waiting with changes until all
affected parties are smooth with it is a recipe for failure.
> > I think applying this complete patch set and keeping fcbfaffee51a ("driver
> > core: add TAINT_FORCED_BIND for when userspace manually messes with devices and
> > drivers") is too much, so this series serves mainly as discussion ground for
> > choosing a sane way to prevent fuzzing results of only mild interest and stop
> > patch sets harding drivers for driver_override handling.
> > My preference would be to revert (or drop) fcbfaffee51a and then only
> > apply patch #3. Maybe also keep patch #2 to taint if
> > "allow_driver_override" is provided.
>
> Agreed, but as mentioned in [1], I think it is also reasonable to only keep
> TAINT_FORCED_BIND for buses that do not support hotplug in the first place.
>
> [1] https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/
Fine for me, that would mean to apply the whole series and restrict
TAINT_FORCED_BIND to "static" busses.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-09-29 5:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 16:46 [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-28 16:46 ` [PATCH v3 1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted Uwe Kleine-König
2026-09-28 17:25 ` Bradley Morgan
2026-09-28 16:46 ` [PATCH v3 2/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-28 16:58 ` sashiko-bot
2026-09-28 19:43 ` Uwe Kleine-König
2026-09-28 17:25 ` Bradley Morgan
2026-09-28 16:46 ` [PATCH v3 3/3] driver core: Disable driver overriding by default Uwe Kleine-König
2026-09-28 16:57 ` sashiko-bot
2026-09-28 19:47 ` Uwe Kleine-König
2026-09-28 17:26 ` Bradley Morgan
2026-09-28 17:15 ` [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Danilo Krummrich
2026-09-29 5:53 ` Uwe Kleine-König [this message]
2026-09-29 10:28 ` Danilo Krummrich
2026-09-28 21:51 ` (subset) " Danilo Krummrich
2026-09-28 21:53 ` Danilo Krummrich
2026-09-29 5:47 ` Uwe Kleine-König
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=artRKXU0jygdcxx3@monoceros \
--to=u.kleine-koenig@baylibre.com \
--cc=W_Armin@gmx.de \
--cc=atomlin@atomlin.com \
--cc=brads@mainlining.org \
--cc=dakr@kernel.org \
--cc=dlechner@baylibre.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=thierry.reding@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.