On Mon, 26 Oct 2026 21:34:57 +0100, Greg Kroah-Hartman wrote: > > Even if we could come up with a set of device IDs, it's a policy > > decision whether a given device is intended by the admin to be used > > by the default in-kernel driver or a userspace driver. > > Great, then have the admin never allow the in-kernel driver to be on > the system, or be loaded (modprobe has deny lists) and all is fine.
As some maintainers like to say, it's not the '90s anymore :) Users don't reboot systems to kick a kernel driver off a PCI device to try something in a disposable VM on a whim. Even if they did, it's completely normal for desktop users to have two GPUs from the same vendor or two xHCI controllers and pass only one of them to Windows/macOS while using the other on the host. bind/unbind feature prominently on every distribution wiki and forum, this cat is absolutely out of the bag at this point. > > That means that at one point we want the default driver bound and at > > another we want a vfio driver bound. Coordinating this is exactly > > why we have driver_override and, building on that, match IDs that > > require driver_override. This allows drivers to describe > > themselves as vfio-pci compatible drivers via modules.alias while > > requiring userspace to enable the match via driver_override. > > And as said before, that's a horrid hack and one that is breaking > things today in all sorts of ways, which is why the taint was added. Are you aware of bind/unbind breaking things for PCI specifically? Without also involving 'driver_override' or 'new_id'? Everyone agrees that these APIs used for anything other than pci-stub or vfio are foot guns. But your patch targets something different. We can even bind PCI drivers to wrong devices *without* using bind and hence, I presume but don't care to test, without tripping this taint. > If you wish to override the kernel, then great, a taint flag is added > and all is fine. All this means is that now developers know what you > did and can decide to ignore your bug report or not. No functionality > changed at all. I believe people pointed out that it's a functional change for users of panic_on_taint who also use bind without being idiots. Does this taint even solve a "real" problem? Those bug reports weren't coming from users, they were coming from "abusers" like syzbot looking for trouble. They were quite obvious even without a taint message. And at least on linux-usb, they seem to have stopped after Google and one other copycat were told to stop sending them, and before this taint reaches released kernels. I even told them to block not only bind but also new_id, so there will be no second wave of reports caused by syzbot discovering that it can bypass the taint by using new_id intsead of driver_override. > Why are you worried about a taint flag? So many servers run with > taint flags enabled due to out-of-tree or questionable licenses with > no problems, what's one more informational bit here? And what's the point of a flag which is always set on countless normal systems in the wild? If this feature survives to April 1st, I will send a patch to rename it to "VM passthrough taint" because everybody (or at least those dealing with desktop users) knows what it *really* means. Regards, Michal
