linux-toradex.git/fs/read_write.c, branch v3.14.3

vfs: atomic f_pos access in llseek()

2014-03-23T04:03:12+00:00

Commit 9c225f2655e36a4 ("vfs: atomic f_pos accesses as per POSIX") changed
several system calls to use fdget_pos() instead of fdget(), but missed
sys_llseek().  Fix it.

Signed-off-by: Eric Biggers 
Signed-off-by: Al Viro

get rid of fget_light()

2014-03-10T15:44:42+00:00

instead of returning the flags by reference, we can just have the
low-level primitive return those in lower bits of unsigned long,
with struct file * derived from the rest.

Signed-off-by: Al Viro

vfs: atomic f_pos accesses as per POSIX

2014-03-10T15:44:41+00:00

Our write() system call has always been atomic in the sense that you get
the expected thread-safe contiguous write, but we haven't actually
guaranteed that concurrent writes are serialized wrt f_pos accesses, so
threads (or processes) that share a file descriptor and use "write()"
concurrently would quite likely overwrite each others data.

This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says:

 "2.9.7 Thread Interactions with Regular File Operations

  All of the following functions shall be atomic with respect to each
  other in the effects specified in POSIX.1-2008 when they operate on
  regular files or symbolic links: [...]"

and one of the effects is the file position update.

This unprotected file position behavior is not new behavior, and nobody
has ever cared.  Until now.  Yongzhi Pan reported unexpected behavior to
Michael Kerrisk that was due to this.

This resolves the issue with a f_pos-specific lock that is taken by
read/write/lseek on file descriptors that may be shared across threads
or processes.

Reported-by: Yongzhi Pan 
Reported-by: Michael Kerrisk 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Al Viro

fs/compat: fix parameter handling for compat readv/writev syscalls

2014-01-30T00:22:39+00:00

We got a report that the pwritev syscall does not work correctly in
compat mode on s390.

It turned out that with commit 72ec35163f9f ("switch compat readv/writev
variants to COMPAT_SYSCALL_DEFINE") we lost the zero extension of a
couple of syscall parameters because the some parameter types haven't
been converted from unsigned long to compat_ulong_t.

This is needed for architectures where the ABI requires that the caller
of a function performed zero and/or sign extension to 64 bit of all
parameters.

Signed-off-by: Heiko Carstens 
Cc: Al Viro 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Cc: 	[v3.10+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/read_write.c:compat_readv(): remove bogus area verify

2014-01-22T00:19:42+00:00

The compat_do_readv_writev() function was doing a verify_area on the
incoming iov, but the nr_segs value is not checked.  If someone passes
in a -1 for nr_segs, for instance, the function should return an EINVAL.
However, it returns a EFAULT because the verify_area fails because it is
checking an array of size MAX_UINT.  The check is bogus, anyway, because
the next check, compat_rw_copy_check_uvector(), will do all the
necessary checking, anyway.  The non-compat do_readv_writev() function
doesn't do this check, so I think it's safe to just remove the code.

Signed-off-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

file->f_op is never NULL...

2013-10-25T03:34:54+00:00

Signed-off-by: Al Viro

aio: Kill aio_rw_vect_retry()

2013-07-30T15:53:12+00:00

This code doesn't serve any purpose anymore, since the aio retry
infrastructure has been removed.

This change should be safe because aio_read/write are also used for
synchronous IO, and called from do_sync_read()/do_sync_write() - and
there's no looping done in the sync case (the read and write syscalls).

Signed-off-by: Kent Overstreet 
Cc: Zach Brown 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Rusty Russell 
Cc: Jens Axboe 
Cc: Asai Thambi S P 
Cc: Selvan Mani 
Cc: Sam Bradshaw 
Cc: Jeff Moyer 
Cc: Al Viro 
Cc: Benjamin LaHaise 
Signed-off-by: Benjamin LaHaise

vfs: export lseek_execute() to modules

2013-07-03T12:23:27+00:00

For those file systems(btrfs/ext4/ocfs2/tmpfs) that support
SEEK_DATA/SEEK_HOLE functions, we end up handling the similar
matter in lseek_execute() to update the current file offset
to the desired offset if it is valid, ceph also does the
simliar things at ceph_llseek().

To reduce the duplications, this patch make lseek_execute()
public accessible so that we can call it directly from the
underlying file systems.

Thanks Dave Chinner for this suggestion.

[AV: call it vfs_setpos(), don't bring the removed 'inode' argument back]

v2->v1:
- Add kernel-doc comments for lseek_execute()
- Call lseek_execute() in ceph->llseek()

Signed-off-by: Jie Liu 
Cc: Dave Chinner 
Cc: Al Viro 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Christoph Hellwig 
Cc: Chris Mason 
Cc: Josef Bacik 
Cc: Ben Myers 
Cc: Ted Tso 
Cc: Hugh Dickins 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Sage Weil 
Signed-off-by: Al Viro

lseek_execute() doesn't need an inode passed to it

2013-06-29T08:57:53+00:00

Signed-off-by: Al Viro

constify rw_verify_area()

2013-06-29T08:57:34+00:00

Signed-off-by: Al Viro