BMC/Intel-BMC/linux.git/fs/coda/file.c, branch dev

make new_sync_{read,write}() static

2015-04-12T02:29:40+00:00

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

coda: switch to ->read_iter/->write_iter

2015-04-12T02:28:52+00:00

... and request the same from the local cache - all filesystems with anything usable for that support those already. Signed-off-by: Al Viro

fs/coda: use linux/uaccess.h

2014-08-08T22:57:20+00:00

Fix checkpatch warning WARNING: Use #include instead of Signed-off-by: Fabian Frederick Cc: Jan Harkes 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

lift sb_start_write() out of ->write()

2013-04-09T18:12:56+00:00

Signed-off-by: Al Viro

new helper: file_inode(file)

2013-02-23T04:31:31+00:00

Signed-off-by: Al Viro

fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers

2011-07-21T00:47:59+00:00

Btrfs needs to be able to control how filemap_write_and_wait_range() is called in fsync to make it less of a painful operation, so push down taking i_mutex and the calling of filemap_write_and_wait() down into the ->fsync() handlers. Some file systems can drop taking the i_mutex altogether it seems, like ext3 and ocfs2. For correctness sake I just pushed everything down in all cases to make sure that we keep the current behavior the same for everybody, and then each individual fs maintainer can make up their mind about what to do from there. Thanks, Acked-by: Jan Kara Signed-off-by: Josef Bacik Signed-off-by: Al Viro

take coda-private headers out of include/linux

2011-01-13T01:02:48+00:00

Signed-off-by: Al Viro

Coda: push BKL regions into coda_upcall()

2010-10-25T15:02:40+00:00

Now that shared inode state is locked using the cii->c_lock, the BKL is only used to protect the upcall queues used to communicate with the userspace cache manager. The remaining state is all local and we can push the lock further down into coda_upcall(). Signed-off-by: Yoshihisa Abe Signed-off-by: Jan Harkes Signed-off-by: Linus Torvalds

Coda: add spin lock to protect accesses to struct coda_inode_info.

2010-10-25T15:02:40+00:00

We mostly need it to protect cached user permissions. The c_flags field is advisory, reading the wrong value is harmless and in the worst case we hit a slow path where we have to make an extra upcall to the userspace cache manager when revalidating a dentry or inode. Signed-off-by: Yoshihisa Abe Signed-off-by: Jan Harkes Signed-off-by: Linus Torvalds