On Mon, 28 Nov 2005, David Brownell wrote: > 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.
Yes, that's what I was concerned about. > 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. For fast responses it doesn't matter, as you say. Slow responses are potentially a problem. > > 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 did put a tag mechanism in g_file_storage. Obviously it's not going to be 100% effective, but it does narrow the window for errors considerably. > 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. Agreed, at the lowest level this is a protocol problem. It can be ameliorated to some extent in the hardware; for instance a device controller might be smart enough to flush the ep0 fifo whenever a SETUP packet arrives. That wouldn't prevent races with the firmware or software, however. Alan Stern ------------------------------------------------------- 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
