Re: [PATCH][RFC] USB: zerocopy support for usbfs

From: Stefan Klug
Date: Thu Jul 03 2014 - 04:22:23 EST



On 02.07.2014 21:38, Alan Stern wrote:
On Wed, 2 Jul 2014, Oliver Neukum wrote:


Stefan Klug
Software Developer

Basler AG
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 4102 463 582
Fax +49 4102 463 46 582

Stefan.Klug@xxxxxxxxxxxxx

www.baslerweb.com

Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender)ÂÂÂJohn P. JenningsÂÂÂArndt Bake ÂÂHardy Mehl
Aufsichtsratsvorsitzender: Norbert Basler Basler AG Â Amtsgericht LÃbeck HRB 4090 Â Ust-IdNr.: DE 135 098 121 Â Steuer-Nr.: 30 292 04497 Â WEEE-Reg.-Nr. DE 83888045
On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:

Implementation details:
The patch only touches drivers/usb/core/devio.c.
In procy_do_submiturb(), it is checked if zerocopy is allowed. This is
currently a rough
check which compares the number of required pages to
ps->dev->bus->sg_tablesize.
It seems to me that the check is per call, so using
multiple calls one could still pin unlimited amounts
of memory.
usbfs keeps track of the total amount of pinned memory and enforces an
overall limit. It will be necessary to add the size of the transfer
buffer to that total.
Leaving the zerocopy transfers out of this limit was intentional. I thought this is user-memory so we shouldn't add it to the overall limit as it is not allocated by usbfs.
But I didn't think of the pinning problem. So yes, I can add it to the overall limit.
I don't know if there is more to check there.
Then the user memory provided inside the usbdevfs_urb structure is
pinned to
physical memory using get_user_pages_fast().
All the user pages are added to the scatter-gather list and the logic
continues as before.
How do you enforce the cache coherency rules?
There is no way to do this. If the user program accesses memory when
it shouldn't, the transfer might not work right.
So this one is fine, right?
Also you don't have a fall back if get_user_pages_fast()
returns less than requested. It seems to me that than you
ought to fall back buffered IO.
Agreed.
Good point. I'll add the fallback to the next iteration.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/