> From: Alan Stern > On Mon, 25 Nov 2013, Xenia Ragiadakou wrote: > > > > You can simplify part of the problem by not allowing an endpoint to be > > > reset if it has any pending URBs. Just fail the reset in this case. > > > > Yes, you are right since, from what i understand, it is the > > responsibility of the device driver to unlink any pending URBs before > > issuing a clear halt to the endpoint. So we expect the device driver to > > call usb_unlink_urb() for each pending URB, which in turn calls > > Actually you should expect the driver to call usb_kill_urb(), not > usb_unlink_urb(). The difference is that usb_kill_urb() waits for the > URB to complete. What happens if the URB completed just before the driver tried to kill it? In this case the xhci code will be performing the upcall into the driver at the same time - chaos is bound to happen. Upcalls are horrid things, very difficult to lock correctly and usually require a 3-way handshake to cancel. IIRC xhci releases its own mutex before making the completion upcall. If it removes the URB from its lists before this, then the cancellation request can reference a URB that no longer exists. If it reacquires the mutex and tidies up afterwards then any cancellation request still has to be rejected - otherwise the driver will tidy up twice. The only obvious solution is that the xhci driver cannot assume the URB address is valid (so must scan the active requests looking for it) and then must call the completion function with a status of 'cancelled'. If is all a lot easier if there are strong constraints on what the driver can do in the upcall function. David -- 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
