On Sunday 27 November 2005 12:46 pm, Alan Stern wrote: > When a control request arrives on ep0 and the gadget has to do a lot of > processing before completing the data or status stages of the request, > there's a possibility that the host might time out and send another > request to ep0. If this happens, there's ambiguity about which request > the data or status stage corresponds to. The host will think it goes with > the second request, but the gadget driver may still be working on the > first.
Yes and no. If the setup() request goes to the gadget driver, and that gadget driver takes a long time to respond (maybe it handed things off to a task that doesn't get scheduled fast enough), that issue could arise. So that'd affect file_storage, and user mode code with gadgetfs, and potentially some out-of-tree code. With RT_PREEMPT, the IRQ handling tasks must be scheduled promptly enough that this doesn't happen. But normally, the SETUP packet is handled faster than that. Either in hardware, or in the controller driver's IRQ handler, or in the gadget driver's setup() handler still in the IRQ handler. It'd not be an issue; hosts won't be issuing a second SETUP packet before the IRQ finishes. > To some extent the gadget driver can avoid this problem by keeping track > of setup requests as they arrive. Assign a tag number to each one, for > example, and don't send a reply if the current tag is different from the > reply's tag. But there's still a race between the setup routine changing > the current tag and the reply routine checking it. We don't have such a mechanism just now. It might be worth adding one; or maybe just a cancel_setup() callback to the gadget driver, so gadget drivers can avoid managing the extra state. (And so that controller drivers could phase in support for this new mechanism over time ... not all of them explicitly track "is there a SETUP response pending".) I don't see a way to defend against hosts misbehaving badly enough to send two back-to-back SETUP packets, but that seems mostly like an issue with the USB protocol itself ... normal RPC protocols include a request ID that's used to disambiguate responses, but this USB-private RPC scheme (SETUP and its responses) doesn't do so. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
