On Tue, 17 Nov 2015, Christoph Hellwig wrote: > On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote: > > In other words, you're suggesting we do this: > > > > Check that userspace requested zerocopy (otherwise the user > > program might try to access other data stored in the same cache > > lines as the buffer while the I/O is in progres); > > > > Call get_user_pages (or get_user_pages_fast? -- it's not clear > > which should be used) for this buffer; > > > > Use the array of pages returned by that routine to populate > > a scatter-gather list (sg_alloc_table_from_pages); > > > > Pass that list to dma_map_sg. > > > > Is that right? > > Yes. > > > Does dma_map_sg check the page addresses against the DMA mask and > > automatically create a bounce buffer, or do we have to do that > > manually? Documentation/DMA-API-HOWTO.txt doesn't discuss this. > > You need to do this manually. I looked through the code. Christoph was wrong about this, at least on systems that support CONFIG_SWIOTLB. Of course, using a bounce buffer kind of defeats the purpose of zerocopy I/O, but I guess sometimes there's no choice. AFAICT this leaves two questions. First, should we worry about systems that don't support SWIOTLB? My feeling is probably not. In fact, the existing DMA mapping code used for ordinary USB communications doesn't try to handle mapping errors by setting up bounce buffers; it assumes that dma_map_sg() takes care of all that. Second, how shall we ask user programs to indicate that they won't access the buffer's memory pages during I/O? My suggestion is that we add a USBDEVFS_URB_ZEROCOPY flag (and a corresponding capability bit). Any objections? Alan Stern -- 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