Looking for candidates to resolve the other issues I've seen, I've came
along the bandwidth operations when submitting iso/int urb's. Well, this
is definitely unrelated to my problems (bulk-only) and I don't have a test
case where it breaks so far. However I believe it's worth to be reported.
When submitting iso/int urb's the HCD's handle bandwidth considerations
basically as follows:
in *hci_submit_urb()
granted_bustime = usb_check_bandwidth(urb)
/* window */
if (granted_bustime > 0) {
ret = do_submit_urb(urb)
/* window */
if (ret == success) {
usb_claim_bandwidth(urb,granted_bustime)
...
Note (uhci.c for example) this happens right after spinlock is released.
Unless I've missed something subtle there's apparently nothing that
protects us from races at indicated windows. Since it's perfectly legal to
call usb_submit_urb() from completion handler (interrupt context) this
would be both a SMP and UP (interrupt) race. Worst case I think is this
might lead to bus-overcommitment.
What about changing usb.c to provide usb_check_and_claim_bandwidth() so
the above would be
granted_bustime = usb_check_and_claim_bandwidth(urb)
if (granted_bustime > 0) {
ret = do_submit_urb(urb);
if (ret != success) {
usb_release_bandwidth(urb,granted_bustime);
...
Of course, both usb_check_and_claim/usb_release_bandwidth() must be
safe too - acquiring some urb->dev->bus->lock for example.
I believe this would be better than locking around the whole thing.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
