limits of usb_kill_urb()

Hi,

I am looking at code in which an interrupt completion handler can either

a) resubmit itself
b) submit a control URB

the control URB will in turn submit the interrupt URB again.

It seems to me that usb_kill_urb() alone cannot be used to cancel IO
without a race condition, as the following race always exists.

CPU A							CPU B
execute interrupt completion
								kill interrupt urb
submit control urb
execute control completion handler
								kill control urb
submit interrupt urb

To safely cancel everything you need:

disconnect():
spin_lock_irq(&lock)
flag = 1;
spin_unlock_irq(&lock)
usb_kill_urb(a)
usb_kill_urb(b)

completion handlers:
spin_lock(&lock)
if (!flag)
	usb_submit_urb([ab], GFP_ATOMIC);
spin_unlock(&flag);

This problem exists if more than two URBs are involved, too. If you take
completion as nodes in a directed graph and submissions as edges, you
need to watch for cycles.

Comments? Should I add a warning to Documentation/URB.txt?

	Regards
		Oliver

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel