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

[Alex Williamson]

On Wed, 28 Oct 2026 15:50:44 +0100
Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx> wrote:

> On Wed, Oct 28, 2026 at 02:45:18PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Oct 26, 2026 at 07:59:50PM -0300, Jason Gunthorpe wrote:  
> > > On Sun, Oct 25, 2026 at 01:48:04PM +0100, Uwe Kleine-König wrote:
> > >   
> > > > The more I think about this taint, the more I believe the commit should
> > > > be reverted and replaced by a some stop gaps for driver_override. (Be it
> > > > a taint or better yet
> > > > https://lore.kernel.org/all/0f7446324f6a0c8f0153d6532d92a6eeecd6a308.1790612298.git.u.kleine-koenig@xxxxxxxxxxxx/
> > > > .)  
> > > 
> > > I also think this patch is way too broad and should be reverted until
> > > something better is designed.  
> > 
> > Fair enough, I've sent a revert for now, will get it merged before -rc1
> > is out.  
> 
> \o/, thanks
> 
> > I'll rework this for a later release, thanks.  
> 
> Please look at the series behind the link above before investing time
> here. I think most of the ideas are already implemented there. If you
> voice your preferences there, I can rework accordingly and rebase on top
> of your revert.

From a vfio perspective, the concern with the linked series is that
driver_override always taints.  That's the same regression we have
here; vfio use cases rely on driver_override.  Introducing a driver
flag that allows a driver to opt-in to declare support for
driver_override, but then taints if it actually generates a match is
contradictory.

I had been working on a series that allowed match to return a match
type classification, for example 1 as a static match (for
compatibility), 2 for a dynamic match, and 3 for a driver_override
match.  Anything other than a static match that reaches driver probe
generates a taint.  Also note that generating a match doesn't
necessarily result in a driver probe callback, in at least one flow we
haven't even tested that the device isn't already bound to a driver.

The bus level match function can filter and downgrade the
classification, for example PCI has an override_only flag in its match
ID.  vfio-pci and variant drivers thereof make use of this to avoid
becoming the default driver for devices.  A driver_override that
matches the override_only match ID in the driver table can be demoted
to a static match and avoid tainting.

I'm not sure I understand the rationale for focusing only on
driver_override though, new_id has just as much ability to generate
bogus driver matches.  It's also racy to use new_id if you're trying to
get a specific device bound to a driver, which is why driver_override
was invented.  So we end up placing barriers to the use of the
interface that we've now long recommended as the better alternative to
new_id, while leaving the gaps in new_id wide open.  Thanks,

Alex