Re: [PATCH 05/17] USB: Lock registered interfaces during manual driver binding

[Leon Romanovsky]

On Sun, Nov 08, 2026 at 11:59:11AM -0500, Alan Stern wrote:
> On Sun, Nov 08, 2026 at 01:09:09PM +0200, Leon Romanovsky wrote:
> > On Thu, Nov 05, 2026 at 03:04:18PM -0500, Alan Stern wrote:
> > > >  it ensures that the lock is
> > > > acquired when the driver is bound.
> > > 
> > > That may have been your intention when the patch was created, but if you 
> > > read the patch you'll see that it includes a whole bunch of material 
> > > not related to locking during binding.  Namely, this part:
> > 
> > Once I added `device_lock()` to `bind`, I had to add it to `unbind` as well.
> 
> Obviously I'm not making my points clear.  Let me try again.
> 
> The entire patch description, as you wrote it, is this:
> 
> > Interface claims hold the USB device lock, but device_bind_driver()
> > requires the target interface lock. Without it, trust-policy writes  can
> > race admission.
> 
> This says nothing about holding the interface lock during unbinding.  In 
> other words, it isn't a complete description of the patch.  It implies 
> that the patch changes nothing outside the device_bind_driver() 
> function, which isn't true.
> 
> Furthermore, the patch does not change any of the code in 
> usb_driver_release_interface(), which is where unbinding takes place, 
> because that routine already takes the interface lock.  So to say that 
> you had to add device_lock() to `unbind` is not accurate.
> 
> Instead the patch adds a new usb_driver_release_refused_claim() routine, 
> plus code in usb_set_configuration() to call the new routine.  The patch 
> description says nothing about either of these things.  Not to mention 
> the fact that your other changes make it now possible for the driver 
> core to delete an interface claim when the interface is registered, 
> something which was not possible before.  This is another inadequacy in 
> the patch description.
> 
> I'm not saying that any of the code is wrong.  But the description does 
> a very bad job of explaining the new code.

I hope v2 explains this better. I also split the USB patch further.

Thanks

> 
> Alan Stern
>