On Wed, 27 Jan 2010, Mike Dunn wrote: > > There is a potential problem, but it's not what you think. The kernel > > will indeed cancel outstanding URBs when unbinding a driver (provided > > soft_unbind isn't set in the usb_driver structure). > > > > Problems can arise because a driver's disconnect function gets called > > whenever the driver is unbound from the device -- which doesn't > > necessarily mean the device has been unplugged. The device may still > > be present and another driver may get bound to it. This can happen > > when you rmmod one driver module and then modprobe a different one, for > > example. > > > Ah, I think I see... the primary hazard is if the driver is completely > removed from memory > while the synchronous call is pending. In that case, the called function > will be returning to > invalid memory. By waiting for the synchronous function to complete > before returning > from disconnect(), this scenario is avoided. I guess this is true of any > synchronous calls > in a kernel module, not specific to usb_control_msg() et.al. It's true for any URB, whether synchronous or not. Fortunately, the core makes it difficult for drivers to have pending URBs when their disconnect routine returns. > And from > what you describe, > there's an additional hazard that a separate unsuspecting driver may be > controlling a device > that receives a phantom message that the driver didn't send. That is the primary issue. > > The worst case is when your driver submits an URB after its disconnect > > routine has returned. The URB won't be cancelled automatically. If > > another driver gets bound to the same device, it will be confused when > > the device responds to this extra URB that the new driver doesn't know > > about. > > > > > Well, this would be a more straightforward programming error, and likely > to cause NULL > pointer dereferences, assuming disconnect cleaned up properly. > > Many thanks again for taking the time to explain! You're welcome. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
