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:
>> 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 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?
>> > 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/[email protected]/
>
> Fine for me, that would mean to apply the whole series and restrict
> TAINT_FORCED_BIND to "static" busses.
That sounds fine to me.
