On Wed, 28 Oct 2026 15:50:44 +0100 Uwe Kleine-König <[email protected]> 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-koe...@baylibre.com/ > > > > .) > > > > > > 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
