Hi Alan, thanks for bringing up this subject. > Currently the synchronous case of usb_unlink_urb() has the following > semantics: If the URB is not in progress the routine returns > immediately with -EBUSY. If the URB is in progress then it is > unlinked, the URB's status is set to -ENOENT, the unlink routine > blocks until the completion function has returned, and then it returns > 0.
This just came up in devio.c: the "synchronous" call to usb_unlink_urb was returning immediately with -EBUSY (probably because the core just nuked the urbs) even though the completion handlers hadn't finished. The code assumed (of course - doesn't everybody?) that the completion handlers had run, and moved on to do bad things, leading to a kernel panic. See http://marc.theaimsgroup.com/?l=linux-usb-users&m=106791218332025&w=2 In my opinion synchronous usb_unlink_urb should not return until completion handlers have been run. If someone has already started unlinking the urb, so much the better: the call should wait until that has finished, then return. > In my opinion these semantics are insufficient. Certainly they are > not appropriate for the way usb_unlink_urb() is actually used in many > drivers. A very hasty survey of source files in drivers/usb/class > showns that most synchronous unlinkers require these semantics > instead: Regardless of whether the URB was in progress or not, when > the routine returns the URB must no longer be linked and must be > available for immediate reuse. Also the completion function must have > already returned so that it can safely be unloaded from memory (as in > rmmod). Resubmission within the completion function doesn't make much > sense in the context of a synchronous unlink, so it wouldn't hurt -- > and indeed it might help -- if the core fails such resubmissions. The > return code from the unlink doesn't really matter since callers > usually don't check it, so there's no harm in continuing to return > -EBUSY if the URB wasn't in progress. I bet nobody checks the return code because they expect the core to do whatever it takes to unlink the urb - even if it takes a long time. After all, by specifying "synchronous" they've stated that they are prepared to wait. Ciao, Duncan. PS: The speedtouch driver gets it right (or so I hope), at the expense of an ugly block of code in the disconnect routine. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
