- 12 Apr, 2015 40 commits
-
-
Al Viro authored
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>
-
Al Viro authored
it's &iocb->ki_pos; no need to obfuscate. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
-
Al Viro authored
it's easier to do generic_write_checks() first Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-
Al Viro authored
simpler that way... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
all remaining callers are passing 0; some just obscure that fact. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-
Omar Sandoval authored
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>
-
Omar Sandoval authored
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>
-
Omar Sandoval authored
And use iov_iter_rw() instead. Signed-off-by:
Omar Sandoval <osandov@osandov.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Omar Sandoval authored
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>
-
Omar Sandoval authored
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>
-
Al Viro authored
no remaining users Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-
Al Viro authored
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>
-
Al Viro authored
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>
-
Al Viro authored
store reference to iter instead of that to iovec Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
we just change the calling conventions here; more work to follow. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-
Al Viro authored
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>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
-
Al Viro authored
... 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>
-
Al Viro authored
... 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>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
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>
-