On Thu, 8 Jun 2006, David Brownell wrote: > On Thursday 08 June 2006 8:26 pm, Alan Stern wrote: > > On Thu, 8 Jun 2006, David Brownell wrote: > > > > > That said, I don't see an obvious race there. If the device disconnects, > > > there's now a guarantee that all pending urbs will have completed before > > > the driver disconnect() method is called. (As of maybe 2.6.8 or so. The > > > original 2.4 code of course couldn't rely on such guarantees. The lack of > > > such guarantees meant a seemingly endless supply of oops-on-disconnect > > > bugs.) > > > > But there's no guarantee that URBs submitted _after_ the disconnect method > > has returned will fail. > > Yes there is ... they fail during submit, since the device is marked > as gone. Submits start failing even before disconnect() is called.
Not if the disconnect was for unbind only, as opposed to unplug. > > (Of course, if the device really has been > > unplugged then they definitely will fail, but if the driver has merely > > been unbound from the interface then they might not.) Drivers do need to > > have sufficient synchronization to avoid this problem. > > Well, the specific scenario here was errors on unplug, not rmmod; Maybe my memory is going... I thought Daniel said the problem would occur when the disconnect() method runs. In other words during unbind as opposed to during either unplug or rmmod. > and I'd call it an error if URBs could be submitted to endpoints > that aren't bound to some driver. (Yep, likely we have bugs in > that space.) The problem is that the endpoints might indeed be bound -- but to a different driver! That is, driver A is unbound from an interface and driver B is then bound to it. What happens if driver A continues to submit URBs? Alan Stern _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
