On Tue, Sep 22, 2026 at 11:04:46PM +0200, Armin Wolf wrote: > Am 22.09.26 um 15:40 schrieb David Lechner: > > > On 9/22/26 2:39 AM, Uwe Kleine-König wrote: > > > On Fri, Sep 18, 2026 at 06:39:02PM +0200, Danilo Krummrich wrote: > > > > On Mon Sep 14, 2026 at 4:30 PM CEST, Greg Kroah-Hartman wrote: > > > > > The ability to add and remove devices from a driver through the sysfs > > > > > "bind" and "unbind" files was created all those decades ago as a way > > > > > that kernel developers can iterate faster, and provide a debugging way > > > > > for users to attempt to add a new device to a driver without having to > > > > > rebuild their kernel. > > > > > > > > > > This api over the years has been abused and recently come under a > > > > > major > > > > > fuzzing "attack" through tools like syzbot which decided that it would > > > > > attempt to just randomly bind any driver to any type of device, > > > > > causing > > > > > loads of unneeded errors and pointless kernel patches to be generated > > > > > by > > > > > unsuspecting new developers. > > > > > > > > > > Handle all of this by adding a new taint flag, TAINT_FORCED_BIND, > > > > > which > > > > > will be set on the driver if the bind/unbind sysfs files are ever > > > > > written to. This lets kernel developers "know" that a user is > > > > > attempting to do something that is not normal, and as such, if the > > > > > kernel breaks they get to keep the shiny pieces laying around on the > > > > > floor. > > > > > > > > > > The flag is 'Y' which was unused, and can remembered as the user is > > > > > "yeeting" the device being operated on here (thrown with force without > > > > > regard for the thing being thrown). > > > > > > > > > > Note, the taint flag gets set _BEFORE_ the bind/unbind callback > > > > > happens, > > > > > as many times crashes/oops/warnings/failures happen within the > > > > > callback, > > > > > and the taint flag needs to be there to show what was being attempted. > > > > > If it were to be set after the callback happens, the oops report would > > > > > not properly reflect what foolishness was being attempted. > > > > > > > > > > Fuzzing tools like syzbot, that doesn't have hand-crafted rules to > > > > > keep > > > > > the tool from hitting bind/unbind, should be run with panic_on_taint > > > > > enabled so that they fall over and don't continue on, thinking that > > > > > they > > > > > actually found a real issue. > > > > > > > > > > Userspace operations that rely on the bind/unbind files > > > > I agree that this should be avoided. > > > > > > > > But I also think the biggest offender really is driver_override. > > > > Specifically, > > > > on a hot-pluggable bus a driver must be complient with the device driver > > > > lifecycle rules and hence shouldn't break on bind/unbind. I think it > > > > would be > > > > nice to not taint the kernel for such busses, and only taint on > > > > driver_override, > > > > as I think we'd still want the bug reports for such cases. > > > > > > > > But I think this is fine to leave for a follow-up. > > > I fully agree. I'm fine and support tainting on driver_override, but > > > bind/unbind are used occasionally in my bubble and I consider drivers > > > not handling that properly buggy. > > I fully agree with this, drivers should correctly implement the lifecycle > model > and not just break when being unbound at a improper time. Drivers suffering > from > this can easily break this way when unloading the associated kernel module, > so this > taint is no solution.
It's a "solution" in that it tells the developer "hey, the user did something odd and unsupported". rmmod is also not a normal operation, there's no requirement that it actually work as it's usually a "best effort" type of thing. > > In the IIO subsystem, unbind/rebind is the de-facto way to reset a wedged > > chip. > > > > A few examples where other reset methods were reject in favor of > > unbind/bind: > > > > https://lore.kernel.org/linux-iio/20240727160216.2488ed29@jic23-huawei/ > > > > This needs documenting as it's custom ABI. Note that we don't often > > accept custom ABI. Particularly not a hook that seems to reset the > > device. If you want to do that, unbind and rebind the whole drive[r] > > so we are in a known state etc. > > > > https://lore.kernel.org/linux-iio/20240720163440.03c713dc@jic23-huawei/ > > > > Firstly as stated below, we don't provide interfaces for this > > because it's a heavy weight process that is most of the effort of > > unbinding and rebinding the driver. So if you need to reset, do that. > > > > https://lore.kernel.org/linux-iio/20250505200609.54756520@jic23-huawei/ > > > > The solution is to run it once at driver bind. Similar to reset > > below, if the usecase needs to re do it then unbinding and rebinding > > the driver reflects the fact we are taking it effectively offline > > for a while. > > > I also consider bind/unbind to be an official API to interact with devices, > so i want to use them in the future with the WMI subsystem. Why? > AFAIK the underlying reason for this series is that some drivers break when > being bound to unsupported devices. However IMHO drivers should verify that > they support a given device inside their .probe callback, and the associated > bus should only match devices with drivers that explicitly claim support for > those devices (ignoring driver_override). 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. 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. thanks, greg k-h
