Alan Stern wrote: > On Wed, 27 Jan 2010 mikedunn@xxxxxxxxxxx wrote: > > >> Hi, >> >> One more, if I may... >> >> The kernel documentation states that synchronization should occur between >> calls to usb_bulk_msg(), usb_control_msg(), etc, and the disconnect function >> so that if disconnect is invoked while any of these calls are pending, it will >> wait for them to complete. But I don't understand the hazard. Presumably, >> usb_bulk_msg(), etc, will return unsuccesfully if this situation occurs, which >> the invoking function can handle. What can (or should) the disconnect >> function do that would cause a problem if a call to usb_control_msg() is still >> pending? Maybe this is related to my last question. >> > > 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. 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. > 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! Mike -- 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
