On Sun, 16 Apr 2017, Rolf Evers-Fischer wrote: > Hi Chris, > > On 04/11/2017 04:33 PM, Christian Gromm wrote: > > Well, this sounds like a workaround to me as you are changing the timing > > by waiting for the URBs to finish. This might prevent the > > race from happening. > > > I personally would rate it rather as a fix than as a workaround, > because the "usb_wait_anchor_empty_timeout()" function doesn't only > change the timing: It ensures that we won't kill any URB which is > just being processed. And this is exactly the failure that we are > observing here. > > > I thought an USB device driver is allowed to kill anchored URBs at any > > time, isn't it? > > > Both functions are described in Documentation/usb/anchors.txt and I > agree: It is not stated clearly that we must always call the > "usb_wait_anchor_empty_timeout()" function before we can call the > "usb_kill_anchored_urbs()" function. > > Probably Oliver Neukum, who has written these functions long time > ago, can explain shortly, if we can call the > "usb_kill_anchored_urbs()" function always - and if not, in which > situation the "usb_wait_anchor_empty_timeout()" function has to be > called in advance. It is not necessary to call usb_wait_anchor_empty_timeout() before calling usb_kill_anchored_urbs(). And, if you have already called usb_wait_anchor_empty_timeout() in a different thread, it is not necessary to wait for that call to return before you call usb_kill_anchored_urbs(). 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
