On Fri, 2018-09-14 at 05:18 +0100, Al Viro wrote: > On Thu, Sep 13, 2018 at 04:52:09PM +0100, David Howells wrote: > > Add two new iterator types to iov_iter: > > > > (1) ITER_MAPPING > > > > This walks through a set of pages attached to an address_space > > that > > are pinned or locked, starting at a given page and offset and > > walking > > for the specified amount of space. A facility to get a > > callback each > > time a page is entirely processed is provided. > > > > This is useful for copying data from socket buffers to inodes > > in > > network filesystems. > > Interesting... Questions: > * what will hold those pages? IOW, where will you > unlock/drop/whatnot > those sucker? > * "callback" sounds dangerous - it appears to imply that you > won't > copy to/from the same page twice. Not true for a lot of iov_iter > users; what > happens if you pass such a beast to them? > * why not simply "build and populate ITER_BVEC aliasing a piece > of mapping", > possibly in "grab" and "grab+lock" variants? Those ITER_MAPPING do > seem to be > related to ITER_BVEC, at the very least. Note, BTW, that > iov_iter_get_pages...() > might mutate into something similar - "build and populate ITER_BVEC > aliasing a piece > of given iov_iter". Or, perhaps, a nicer-on-memory analogue of > ITER_BVEC - > with <offset, bytes, pointer to pages array> instead of <offset, > bytes, page> as > elements, with the same "populate from mapping" to get something > similar to your > functionality and "populate from iov_iter" for iov_iter_get_pages... > replacement. Another question that is relevant for most networked filesystems (including AFS, I believe), is how will you deal with encryption of the data you are transmitting? Encrypting and decrypting in-place directly in the page cache or in a userspace O_DIRECT mapped buffer might not be the best and most secure option, so won't you find yourself wanting to copy the data anyway? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
