- 12 Apr, 2015 40 commits
-
-
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>
-
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
do it in ->direct_IO()... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
... and make it loop Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
just handle it in ->direct_IO() 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
Don't mess with kmap() - just use ITER_BVEC. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-