On Friday 21 January 2005 11:51 am, Alan Stern wrote: > On Fri, 21 Jan 2005, David Brownell wrote: > > > > In particular, the routine isn't careful about not copying more than > > > wLength bytes for small transfers. > > > > It's careful about not writing more than urb->transfer_buffer_length > > though, and insists wLength not exceed that... how then could that > > routine copy more than wLength? > > One example will demonstrate the point. Look at what happens when typeReq > == (DeviceRequest | USB_REQ_GET_STATUS) (that's the first case in the > big switch statement) and wLength == 0 or 1.
OK. Now, who would do such a silly thing? :) The fix discussed below could address this, too. > > > And when handling class requests > > > there's no way for the HCD's hub_control() routine to set the proper value > > > in urb->actual_length. (The hub_control routines aren't careful not to > > > copy more than wLength bytes either.) > > > > Hmm, I remember thinking they wouldn't need to do that because they'd > > always be copying into a temporary buffer, but I see that's not how > > they work. In this case, it's much better to keep all error checking > > out of the HCDs. > > Agreed. > > > If the temporary buffer in rh_call_control() were big enough to hold a > > usb_hub_descriptor there'd be no problem, since that's bigger than either > > hub or port status (both are LE32), and those are the only values returned > > by HCDs. Just set "bufp" to that before calling the HCD. > > Okay, I'll do that. How do you suggest getting the actual_length value > back from the HCD? Interpret non-negative status return as actual_length? > Add an additional pointer-to-int argument to hub_control? Either way, the > HCDs will have to be changed. Nah, just keep it simple. The HCD (and that switch statement) should be able to rely on a big-enough scratch buffer in all cases. Then make all IN transfers memcpy() the right amount from that buffer ... no changes needed to the HCDs. - Dave > > Alan Stern > > ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel