Re: [PATCH v4 0/3] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers

[Alex Williamson <alex@shazbot.org>]

On Wed, 23 Sep 2026 12:29:56 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Wed, Sep 23, 2026 at 11:54:50AM +0200, Uwe Kleine-König wrote:
> > > No, drivers should NOT have to do that in their .probe() function,
> > > that's what we moved away from decades ago!  The match function should
> > > handle all of that for you, otherwise it's contant duplication
> > > everywhere that is unneeded.  
> > 
> > Well then you have to accept that root can provoke a null pointer
> > exception (e.g. by forcing the pwm-tegra driver on a device) because at
> > least with today's platform bus match function such a match is ok.  
> 
> Agreed, yes, root can cause a crash and can do tons of horrible things
> much worse than this, that's not the issue.
> 
> That's why this taint is there, to make it obvious that this is not a
> "real" bug at all.
> 
> > > Please, learn from our history, don't make the same mistakes.
> > > 
> > > Now I might be convinced that driver_override is the way to go here, but
> > > it still feels really odd as again, bind/unbind was created as a driver
> > > debugging option only, it should NOT be a normal operation that any user
> > > should rely on.  The driver should "just work" properly instead, without
> > > requiring manual bind work, as that's not a good model at all.  
> > 
> > I agree in principle, but (in my case wifi) drivers are buggy sometimes
> > (due to missing documentation and/or engineering effort) and being able
> > to rebind the driver instead of rebooting to get a working device again
> > is very useful.  
> 
> Fine, use it!  Just don't expect that to be "normal".
> 
> > So yes, theoretically bind/unbind isn't needed, but theory and practise
> > differ in practise.  
> 
> Agreed, but again, don't rely on this as a "real" solution fo ranything.

Sorry, late to the party, but this isn't a few user scripts that rely
on this behavior.  Effectively every use case of vfio relies on this
behavior.  We rely on unbinding the default driver from the device
before using driver_override and drivers_probe.  That means every
hypervisor with device assignment and every userspace driver use case
now experiences a tainted kernel. That seems like a significant
regression.

There is currently no alternative for this process.  It's not a matter
of upgrading to a newer kernel where the drivers claim the device IDs.
We can't claim the device ID, vfio drivers represent a secondary use
case for the device.

A production use case of panic_on_taint now results in a hard failure
for a scenario that has been allowed and documented as best practice
for many years.

What's the solution we can pursue for the scenario where devices have
dual use cases between in-kernel drivers and userspace drivers?  Thanks,

Alex