Re: [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

On Tue Sep 29, 2026 at 7:53 AM CEST, Uwe Kleine-König wrote:

On Mon, Sep 28, 2026 at 07:15:12PM +0200, Danilo Krummrich wrote:

quoted

On Mon Sep 28, 2026 at 6:46 PM CEST, Uwe Kleine-König wrote:

quoted

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 do see an advantage in having the taint in match() rather than store(), so I
prefer that too.

But again, I do not feel comfortable to taint the kernel for something that does
use the wrong API but otherwise behaves correctly and shouldn't taint the kernel
at all.

We have six users of device_set_driver_override() outside of a userspace
reachable scope. Did you have a look at how hard they are to fix? Do you plan to
provide patches?

quoted

quoted

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/ (local)

Fine for me, that would mean to apply the whole series and restrict
TAINT_FORCED_BIND to "static" busses.

That sounds fine to me.