On Tue, 17 Feb 2015, Devin Heitmueller wrote: > Hi there, > > I've got a driver which maintains a pool of URBs, properly created via > usb_alloc_urb(). Separately I have a cleanup function which destroys > the pool by looping through the list and calling usb_kill_urb(), > freeing the urb->transfer_buffer, and then calling usb_free_urb(). > > There are some edge cases where not all of the URBs may be in a > submitted state when calling the cleanup function. Could this cause a > problem? Is it legal to call usb_kill_urb() against a URB that hasn't > had usb_submit_urb() called against it (or where the URB had been > submitted but it has already completed and wasn't resubmitted)? Yes, it is legal. Otherwise drivers would be faced with unavoidable races and no way to prevent them. The same is true for usb_unlink_urb(). Alan Stern > I can certainly add additional logic to keep track of exactly which > URBs in the pool are in a submitted state (so I call usb_kill_urb() > against only submitted URBs but usb_free_urb against all URBs), but I > would obviously prefer to avoid the headache and risk of additional > bugs if it isn't necessary. > > Thanks, > > Devin > > -- 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
