Just a side note, for older videodevices it was also common to allocate the DMA memory during bootup because it might have failed during runtime because of memory fragmentation. The reason for the memset on the isochronous transfer is that USB might not fill up the entire buffer leaving half of the isochronous buffer with raw data. On bulk transfers the memset is not needed. So only mapping the urbs to userspace is no solution either. Such kind of security is a little bit odd for a stack that doesn't work nearly as well as Mac or Windows. On userspace side many distributions grant normal users raw access to USB devices as well nowadays. On Tue, Nov 17, 2015 at 7:42 PM, Steinar H. Gunderson <sgunderson@xxxxxxxxxxx> wrote: > On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote: >> 1. the memset on isochronous transfers to empty the buffers in order >> to avoid leaking raw memory to userspace (this costs a lot on intel >> Atoms and is also noticeable on other systems). >> >> 2. the memory fragmentation. Seems like recent systems have a better >> performance here since we did not get that report for several months >> now, or maybe the user behavior changed. >> Some older Linux systems (maybe 2-3 years old) triggered this issue >> way more often. > > I guess if we get transparent zerocopy, both of these are going away > just like with your patch, right? The only difference is really who sets up > the memory area (the kernel or not). > > Alan, could we perhaps let the zerocopy flag make the request fail (instead > of going through a bounce buffer) if direct DMA is not possible? That way, > it would be quite obvious that you need to allocate the memory some other way > instead of silently hitting the issues Markus mention. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
