On Sat, 24 Oct 2026 06:56:34 +0200 Greg Kroah-Hartman <[email protected]> wrote:
> 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 <[email protected]> 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. > > Or finally, a real bugfix :) > > > 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. > > How can vfio know that it can properly talk to any device like this? > Surely you have a list of real device ids that you know will work, > otherwise all bets are off. There's not a list of real device IDs. PCI, in particular, is a self-describing bus. Devices are discovered via bus walk, their resources are probed via standard mechanisms, they support interrupts and resets as described by capabilities defined in a specification. The vfio-pci driver just provides a generic way to represent a device as resources mapped to file offsets with ioctls to discover those offsets and interact with things like resets and interrupts. For example, PCI config space and BAR regions are just defined indexes into the table of file offsets. This works with any endpoint device, where even that distinction is based on the discoverable PCI header type rather than a table of device IDs. 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. This policy changes over time, within the same host session. 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. This is how vfio-pci variant drivers work. These drivers contain device specific knowledge, for instance the ability to serialize and expose device state for migration, but they're still a secondary use case to the in-kernel drivers. This is effort and coordination with subsystems and driver-core over many years and relied on by every hypervisor, now deemed unsupported through a kernel taint before we can even bind the driver. > > 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. > > It was never "best practice", you took a debugging option and somehow > thought it was a valid use case. Yes, I'm being harsh but I am sure I > complained about this in the past and obviously never followed up on it, > so that's on me. I won't doubt that you know more about the history and intent of these interfaces than nearly anyone, but I don't find any documentation or comments that specifically declare these as debug interfaces. In fact, Documentation/ABI/testing/sysfs-bus-pci has documented the bind and unbind ABI for over 20 years. You've certainly expressed more than once that users get to keep all the broken pieces if they bind devices to drivers that don't support the hardware. This is the first that it's been formalized in a taint without warning or an escape hatch for drivers like vfio-pci that do in fact intend to work with all hardware. It affects the industries that depend on this usage model. It's a regression. > > What's the solution we can pursue for the scenario where devices have > > dual use cases between in-kernel drivers and userspace drivers? Thanks, > > So what is the real use case here, taking any type of any device and > thinking you can bind a random kernel driver to it and it will work ok? > You all have specific platform and pci vfio drivers, why not use the > proper device ids there instead, or better yet, bake-in this type of > functionality into the bus-specific logic so that you can have generic > userspace control of a device (like usbfs and uio does today)? > > We have real problems with random "bind/unbind" attempts that this taint > is here to help resolve as it was creating hundreds of false-positive > bug reports on developers all across the tree now that the fuzzers > decided to think this was a valid action to take. Without this taint, > people were being forced to add hacks to all drivers for this which is > not an acceptable solution. At its core, vfio is describing the fundamental aspects of a device, regions and interrupts, without purporting to know anything about the specific programming model of the hardware. In the case of PCI, the vfio-pci driver effectively decomposes the PCI representation of the device into a set of ioctls and a file descriptor. A userspace driver, for example QEMU, recomposes that representation back into a virtual PCI device to the VM with virtualization, emulation, and direct access wired through to the physical device. There are no devices deemed only for vfio use by default. Often we're unbinding a device from the host, exporting it to a userspace driver through vfio, exposing it to a VM, only to bind the same driver to it in the guest that it was previously using in the host. Binding to a vfio driver is always a secondary use case governed by the policy of the system. We cannot create scenarios where there are competing drivers for a device. The vfio driver is always brought into the picture via driver_override, and except in the rare case where no host driver exists, unbind must be used to release the device for drivers_probe. Is there some way instead that we can resolve the string written to driver_override and only taint for non-vfio drivers? It's a much more confined problem if vfio drivers filter hardware outside their scope of support in their .probe function, and I think we largely do that already. Thanks, Alex
