On Mon, 17 Dec 2012, Chen Gang wrote: > 于 2012年12月17日 11:08, Alan Stern 写道: > > It is pretty much as I explained in my previous email. > > > > finish_urb calls usb_free_priv while holding the lock. Then while > > still holding the lock, it calls usb_hcd_unlink_urb_from_ep. > > > > In addition, ohci_urb_dequeue calls usb_hcd_check_unlink_urb while > > holding the lock, and does nothing if the return value is nonzero. > > > > So all you need to do is verify that after usb_hcd_unlink_urb_from_ep > > runs, usb_hcd_check_unlink_urb will always return a nonzero value. In > > fact, it will return -EIDRM -- until the next time the URB is submitted > > and usb_hcd_link_urb_to_ep is called. > > it is true for ohci_urb_dequeue. > how about finish_unlinks and takeback_td in drives/usb/host/ohci-q.c ? > (they also can call finish_urb). Those routines, like almost all the rest of the driver, look at TDs that haven't been processed yet and URBs that haven't been completed yet. Once a TD is processed, it is freed. Since finish_urb isn't called until all the TDs in an URB have been processed, urb->hcpriv will be a valid pointer for any URB encountered. The only places where this isn't true is while an URB is being submitted. The submission routines are careful to free all the private data structures if the URB is not accepted. 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
