Page MenuHomeFreeBSD

libusb: dequeue next transfer on completion to prevent stalls
ClosedPublic

Authored by bapt on Sun, Feb 15, 6:20 PM.
Tags
None
Referenced Files
F145803614: D55289.diff
Tue, Feb 24, 4:52 PM
Unknown Object (File)
Mon, Feb 23, 9:55 PM
Unknown Object (File)
Mon, Feb 23, 5:04 PM
Unknown Object (File)
Mon, Feb 23, 11:06 AM
Unknown Object (File)
Sun, Feb 22, 10:14 AM
Unknown Object (File)
Tue, Feb 17, 7:20 AM
Unknown Object (File)
Mon, Feb 16, 2:57 PM
Unknown Object (File)
Mon, Feb 16, 11:56 AM
Subscribers

Details

Summary

The transfer proxy callbacks (bulk/interrupt, control, isochronous)
only called libusb10_submit_transfer_sub() in the START path to
pipeline the second kernel transfer slot. On completion or error,
no attempt was made to dequeue the next pending transfer from
tr_head onto the now-free slot.

When more than two async transfers were submitted on the same
endpoint, the third (and subsequent) transfers would remain stuck
on tr_head indefinitely, since no completion ever triggered their
submission. This caused a protocol-level deadlock in applications
like adb that submit header + payload + zero-length terminator as
three separate bulk transfers in sequence.

Fix by calling libusb10_submit_transfer_sub() after every
libusb10_complete_transfer() in all three proxy callbacks.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 70678
Build 67561: arc lint + arc unit