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

[Leon Romanovsky]

On Fri, Oct 23, 2026 at 06:13:26PM -0600, Alex Williamson wrote:
> On Wed, 23 Sep 2026 12:29:56 +0200
> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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.

Sorry, I was on vacation and missed this change earlier. This change will
affect SR-IOV deployments around the world, which *rely* on being able to
bind a driver manually *after* virtual functions are created but before
they are used.

This is needed for two reasons: to save hardware and software resources
when creating a large number of VFs, and to allow the PCI config space to
be configured *before* the driver starts using it.

There is no in-kernel alternative.

Thanks