Re: [syzbot] [usb?] INFO: task hung in unbind_store

On Sun, Aug 23, 2026 at 07:28:10PM +0200, Greg KH wrote:
> On Sun, Aug 23, 2026 at 10:40:03AM -0400, Alan Stern wrote:
> > On Sun, Aug 23, 2026 at 01:46:43PM +0200, Greg KH wrote:
> > > Ok, I'm going to add a new TAINT flag for when unbind is written to as
> > > that is obviously not a normal operation and is only for debugging
> > > things by kernel developers.  Adding loads of work-arounds in the kernel
> > > for this not-real-workload-path is just not required.
> > > 
> > > If syzbot could stop hitting this path, that would be great, as it's a
> > > root-only thing for debugging and not something "real".
> > 
> > Actually, I could imagine people wanting to use unbind for a real 
> > purpose -- you could consider it to be a more specific form of modprobe 
> > blacklisting.
> 
> If you want to do that, just don't load the module :)

No, because unbinding is more precise.  You can unbind a driver from one 
particular device.  Not loading the module affects all the devices the 
driver might bind to.

> > The bind attribute is the one which really should taint the kernel, 
> > because it bypasses the normal matching checks.  Also, all the numerous 
> > syzbot bug reports coming out lately have involved weird bind 
> > operations, not unbind.  Unbind should pretty much always work.
> 
> "always work" is tough due to the races that can, and will, happen for
> many non-hotplugged bus devices, as syzbot is finding now.  We shouldn't
> require this, as again, it's a debugging thing.

If a driver does not support hotplugging, shouldn't it disable the bind 
and unbind attributes?  (Is that possible?  If not, it should be.)

But if a driver does support hotplugging, unbinding it should definitely 
work every time.

Alan Stern