David Brownell wrote:
Actually those checks should live in the main urb submit paths,
leaving HCDs to test only for limits that are _lower_ than the
ones allowed in the spec. (For example, some silicon might
be configured with zero, or limited, support for transferring
more than one KByte per microframe.)
So OHCI would fail cleanly there.
It looks like OHCI already checks for limits such as the 1024-byte
cap on EP0 data. Good.
Makes sense, but I think it's normally better to strip out
illegal values as early as practical. It's one of those
programming-101 sorts of policies that will be argued
against later in programming-330.
But that's the problem- it isn't possible to check the limits
in a platform specific way in usbfs. Unless some interface were
added for querying the maximum size from the HCD, it has to
enforce arbitrary limits.
Best of course would be never copying the I/O buffers at all,
just using get_user_pages() to morph the userspace buffer into
a kernel scatterlist. (For non-control paths.) But nobody
seems to want take the next "endpoint per filedescriptor"
steps any time soon.
Yes, this would be great :)
But until that happens, I think it's usbfs's job to enforce only
those limits necessary to keep kernel memory pressure reasonable.
This is why in my other patch I chose PAGE_SIZE*2 as the new limit
for SETUP buffers. A limit of PAGE_SIZE+8 isn't going to help
police kernel memory usage any more than a limit of PAGE_SIZE*2.
In either case, OHCI would catch and reject large packets after
usbfs has copies the buffer.
As for this isochronous packet length patch, is there any reason
to limit the length of individual packets at all? I left the arbitrary
limit on total URB length intact. The only reason I can think of is
to avoid arithmetic overflow- in which case a much larger limit
would still be acceptable.
--Micah
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
