summaryrefslogtreecommitdiffstats
path: root/fs/isofs/export.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2015-04-12ocfs2: move generic_write_checks() before the alignment checksAl Viro1-24/+18
Alignment checks for dio depend upon the range truncation done by generic_write_checks(). They can be done as soon as we got ocfs2_rw_lock() and that actually makes ocfs2_prepare_inode_for_write() simpler. The only thing to watch out for is restoring the original count in "unlock and redo without dio" case. Position doesn't need to be restored, since we change it only in O_APPEND case and in that case it will be reassigned anyway. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ocfs2_file_write_iter: stop messing with pposAl Viro1-12/+12
it's &iocb->ki_pos; no need to obfuscate. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12udf_file_write_iter: reorder and simplifyAl Viro1-20/+14
it's easier to do generic_write_checks() first Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12fuse: ->direct_IO() doesn't need generic_write_checks()Al Viro1-8/+3
already done by caller. We used to call __fuse_direct_write(), which called generic_write_checks(); now the former got expanded, bringing the latter to the surface. It used to be called all along and calling it from there had been wrong all along... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ext4_file_write_iter: move generic_write_checks() upAl Viro1-19/+20
simpler that way... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12xfs_file_aio_write_checks: switch to iocb/iov_iterAl Viro1-15/+16
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12generic_write_checks(): drop isblk argumentAl Viro14-60/+36
all remaining callers are passing 0; some just obscure that fact. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12blkdev_write_iter: expand generic_file_checks() call in thereAl Viro1-6/+9
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12lift generic_write_checks() into callers of __generic_file_write_iter()Al Viro5-30/+60
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12__generic_file_write_iter: keep ->ki_pos and return value consistentAl Viro1-14/+10
A side effect worth noting: in O_APPEND case we set ->ki_pos early, so if it turns out to be an error or a zero-length write, we'll end up with ->ki_pos modified. Safe, since all callers never look at the ->ki_pos after the call of __generic_file_write_iter() returning non-positive, all the way to caller of ->write_iter() and those discard ->ki_pos when getting that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12cifs: fold cifs_iovec_write() into the only callerAl Viro1-31/+16
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ntfs: move iov_iter_truncate() closer to generic_write_checks()Al Viro1-52/+29
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12new_sync_write(): discard ->ki_pos unless the return value is positiveAl Viro1-1/+2
That allows ->write_iter() instances much more convenient life wrt iocb->ki_pos (and fixes several filesystems with borderline POSIX violations when zero-length write succeeds and changes the current position). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12direct_IO: remove rw from a_ops->direct_IO()Omar Sandoval31-59/+42
Now that no one is using rw, remove it completely. Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12direct_IO: use iov_iter_rw() instead of rw everywhereOmar Sandoval22-69/+69
The rw parameter to direct_IO is redundant with iov_iter->type, and treated slightly differently just about everywhere it's used: some users do rw & WRITE, and others do rw == WRITE where they should be doing a bitwise check. Simplify this with the new iov_iter_rw() helper, which always returns either READ or WRITE. Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12Remove rw from dax_{do_,}io()Omar Sandoval5-21/+20
And use iov_iter_rw() instead. Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12Remove rw from {,__,do_}blockdev_direct_IO()Omar Sandoval20-74/+67
Most filesystems call through to these at some point, so we'll start here. Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12new helper: iov_iter_rw()Omar Sandoval1-0/+8
Get either READ or WRITE out of iter->type. Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12->aio_read and ->aio_write removedAl Viro8-54/+9
no remaining users Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12pcm: another weird API abuseAl Viro1-19/+20
readv() and writev() should _not_ ignore all but the first ->iov_len, among other things. Really weird abuse of those syscalls - it expects a vector element per channel, with identical lengths (it actually assumes them to be identical - no checking is done). readv() and writev() are really bad match for that. Unfortunately, userland API is userland API and we can't do anything about them. Converted to ->read_iter/->write_iter. Please, _please_ don't do anything of that kind when designing new interfaces. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12infinibad: weird APIs switched to ->write_iter()Al Viro2-15/+23
Things Not To Do When Writing A Driver, part 1001st: have writev() and write() on the same file doing completely different things. As in, "interpret very different sets of commands". We _can_ handle that, but it's a bloody bad idea. Don't do that in new drivers. Ever. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12kill do_sync_read/do_sync_writeAl Viro2-40/+0
all remaining instances of aio_{read,write} (all 4 of them) have explicit ->read and ->write resp.; do_sync_read/do_sync_write is never called by __vfs_read/__vfs_write anymore and no other users had been left. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12fuse: use iov_iter_get_pages() for non-splice pathAl Viro1-24/+17
store reference to iter instead of that to iovec Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12fuse: switch to ->read_iter/->write_iterAl Viro1-12/+14
we just change the calling conventions here; more work to follow. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12switch drivers/char/mem.c to ->read_iter/->write_iterAl Viro1-9/+9
Note that _these_ guys have ->read() and ->write() left in place - they are eqiuvalent to what we'd get if we replaced those with NULL, but we are talking about hot paths here. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12make new_sync_{read,write}() staticAl Viro59-153/+11
All places outside of core VFS that checked ->read and ->write for being NULL or called the methods directly are gone now, so NULL {read,write} with non-NULL {read,write}_iter will do the right thing in all cases. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12coredump: accept any write methodAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12switch /dev/loop to vfs_iter_write()Al Viro1-5/+7
all writable files that might be used as backing store for /dev/loop already support ->write_iter() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12serial2002: switch to __vfs_read/__vfs_writeAl Viro1-12/+6
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ashmem: use __vfs_read()Al Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12export __vfs_read()Al Viro1-8/+5
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12autofs: switch to __vfs_write()Al Viro2-2/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12new helper: __vfs_write()Al Viro2-12/+17
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12switch hugetlbfs to ->read_iter()Al Viro1-58/+34
... and fix the case when the area we are asked to read crosses a hugepage boundary Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12coda: switch to ->read_iter/->write_iterAl Viro1-25/+15
... and request the same from the local cache - all filesystems with anything usable for that support those already. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ncpfs: switch to ->read_iter/->write_iterAl Viro3-63/+37
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12net/9p: remove (now-)unused helpersAl Viro2-43/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12p9_client_attach(): set fid->uid correctlyAl Viro1-0/+1
it's almost always equal to current_fsuid(), but there's an exception - if the first writeback fid is opened by non-root *and* that happens before root has done any lookups in /, we end up doing attach for root. The current code leaves the resulting FID owned by root from the server POV and by non-root from the client one. Unfortunately, it means that e.g. massive dcache eviction will leave that user buggered - they'll end up redoing walks from / *and* picking that FID every time. As soon as they try to create something, the things will get nasty. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: we are leaking glock.client_id in v9fs_file_getlock()Al Viro1-0/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: switch to ->read_iter/->write_iterAl Viro1-44/+39
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: get rid of v9fs_direct_file_read()Al Viro2-51/+12
do it in ->direct_IO()... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: switch p9_client_read() to passing struct iov_iter *Al Viro7-183/+108
... and make it loop Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: get rid of v9fs_direct_file_write()Al Viro2-82/+17
just handle it in ->direct_IO() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: fold v9fs_file_write_internal() into the callerAl Viro2-49/+30
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: switch ->writepage() to direct use of p9_client_write()Al Viro1-22/+13
Don't mess with kmap() - just use ITER_BVEC. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: switch p9_client_write() to passing it struct iov_iter *Al Viro4-97/+62
... and make it loop until it's done Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12net/9p: switch the guts of p9_client_{read,write}() to iov_iterAl Viro4-133/+147
... and have get_user_pages_fast() mapping fewer pages than requested to generate a short read/write. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12nommu: use __vfs_read()Al Viro1-2/+2
... instead of open-coding the call of ->read() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12acct: check FMODE_CAN_WRITEAl Viro1-1/+1
it's not calling ->write() directly anymore. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12aio_run_iocb(): kill dead checkAl Viro1-7/+0
We check if ->ki_pos is positive. However, by that point we have already done rw_verify_area(), which would have rejected such unless the file had been one of /dev/mem, /dev/kmem and /proc/kcore. All of which do not have vectored rw methods, so we would've bailed out even earlier. This check had been introduced before rw_verify_area() had been added there - in fact, it was a subset of checks done on sync paths by rw_verify_area() (back then the /dev/mem exception didn't exist at all). The rest of checks (mandatory locking, etc.) hadn't been added until later. Unfortunately, by the time the call of rw_verify_area() got added, the /dev/mem exception had already appeared, so it wasn't obvious that the older explicit check downstream had become dead code. It *is* a dead code, though, since the few files for which the exception applies do not have ->aio_{read,write}() or ->{read,write}_iter() and for them we won't reach that check anyway. What's more, even if we ever introduce vectored methods for /dev/mem and friends, they'll have to cope with negative positions anyway, since readv(2) and writev(2) are using the same checks as read(2) and write(2) - i.e. rw_verify_area(). Let's bury it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 04:14:27 +0100