user/sven/linux.git/include/linux/uio.h, branch v4.4.125

constify iov_iter_count() and iter_is_iovec()

2016-12-10T18:07:25Z

commit b57332b4105abf1d518d93886e547ee2f98cd414 upstream. [stable note, need this to prevent build warning in commit a0ac402cfcdc904f9772e1762b3fda112dcc56a0] Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

fix iov_iter_fault_in_readable()

2016-09-24T08:07:43Z

commit d4690f1e1cdabb4d61207b6787b1605a0dc0aeab upstream. ... by turning it into what used to be multipages counterpart Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

new helper: iov_iter_rw()

2015-04-12T02:29:44Z

Get either READ or WRITE out of iter->type. Signed-off-by: Omar Sandoval Signed-off-by: Al Viro

Merge branch 'iov_iter' into for-next

2015-04-12T02:26:51Z

VFS: Add iov_iter_fault_in_multipages_readable()

2015-04-12T02:24:32Z

simillar to iov_iter_fault_in_readable() but differs in that it is not limited to faulting in the first iovec and instead faults in "bytes" bytes iterating over the iovecs as necessary. Also, instead of only faulting in the first and last page of the range, all pages are faulted in. This function is needed by NTFS when it does multi page file writes. Signed-off-by: Anton Altaparmakov Signed-off-by: Al Viro

saner iov_iter initialization primitives

2015-03-30T15:08:16Z

iovec-backed iov_iter instances are assumed to satisfy several properties: * no more than UIO_MAXIOV elements in iovec array * total size of all ranges is no more than MAX_RW_COUNT * all ranges pass access_ok(). The problem is, invariants of data structures should be established in the primitives creating those data structures, not in the code using those primitives. And iov_iter_init() violates that principle. For a while we managed to get away with that, but once the use of iov_iter started to spread, it didn't take long for shit to hit the fan - missed check in sys_sendto() had introduced a roothole. We _do_ have primitives for importing and validating iovecs (both native and compat ones) and those primitives are almost always followed by shoving the resulting iovec into iov_iter. Life would be considerably simpler (and safer) if we combined those primitives with initializing iov_iter. That gives us two new primitives - import_iovec() and compat_import_iovec(). Calling conventions: iovec = iov_array; err = import_iovec(direction, uvec, nr_segs, ARRAY_SIZE(iov_array), &iovec, &iter); imports user vector into kernel space (into iov_array if it fits, allocated if it doesn't fit or if iovec was NULL), validates it and sets iter up to refer to it. On success 0 is returned and allocated kernel copy (or NULL if the array had fit into caller-supplied one) is returned via iovec. On failure all allocations are undone and -E... is returned. If the total size of ranges exceeds MAX_RW_COUNT, the excess is silently truncated. compat_import_iovec() expects uvec to be a pointer to user array of compat_iovec; otherwise it's identical to import_iovec(). Finally, import_single_range() sets iov_iter backed by single-element iovec covering a user-supplied range - err = import_single_range(direction, address, size, iovec, &iter); does validation and sets iter up. Again, size in excess of MAX_RW_COUNT gets silently truncated. Next commits will be switching the things up to use of those and reducing the amount of iov_iter_init() instances. Signed-off-by: Al Viro

new helper: dup_iter()

2015-02-18T03:21:11Z

Copy iter and kmemdup the underlying array for the copy. Returns a pointer to result of kmemdup() to be kfree()'d later. Signed-off-by: Al Viro

Merge branch 'iov_iter' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2015-02-17T23:48:33Z

Pull iov_iter updates from Al Viro: "More iov_iter work - missing counterpart of iov_iter_init() for bvec-backed ones and vfs_read_iter()/vfs_write_iter() - wrappers for sync calls of ->read_iter()/->write_iter()" * 'iov_iter' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fs: add vfs_iter_{read,write} helpers new helper: iov_iter_bvec()

vhost: vhost_scsi_handle_vq() should just use copy_from_user()

2015-02-04T06:34:16Z

it has just verified that it asks no more than the length of the first segment of iovec. And with that the last user of stuff in lib/iovec.c is gone. RIP. Cc: Michael S. Tsirkin Cc: Nicholas A. Bellinger Cc: kvm@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Al Viro

vhost: don't bother copying iovecs in handle_rx(), kill memcpy_toiovecend()

2015-02-04T06:34:16Z

Cc: Michael S. Tsirkin Cc: kvm@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Al Viro