diff options
author | Christoph Hellwig <hch@lst.de> | 2008-12-22 21:11:15 +0100 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2009-01-05 11:54:28 -0500 |
commit | 4c728ef583b3d82266584da5cb068294c09df31e (patch) | |
tree | 1252fa82b5a7cf60c0898c3da810228b4c34ebb3 /include/crypto | |
parent | 6110e3abbff8b785907d4db50240e63c1be726e3 (diff) | |
download | op-kernel-dev-4c728ef583b3d82266584da5cb068294c09df31e.zip op-kernel-dev-4c728ef583b3d82266584da5cb068294c09df31e.tar.gz |
add a vfs_fsync helper
Fsync currently has a fdatawrite/fdatawait pair around the method call,
and a mutex_lock/unlock of the inode mutex. All callers of fsync have
to duplicate this, but we have a few and most of them don't quite get
it right. This patch adds a new vfs_fsync that takes care of this.
It's a little more complicated as usual as ->fsync might get a NULL file
pointer and just a dentry from nfsd, but otherwise gets afile and we
want to take the mapping and file operations from it when it is there.
Notes on the fsync callers:
- ecryptfs wasn't calling filemap_fdatawrite / filemap_fdatawait on the
lower file
- coda wasn't calling filemap_fdatawrite / filemap_fdatawait on the host
file, and returning 0 when ->fsync was missing
- shm wasn't calling either filemap_fdatawrite / filemap_fdatawait nor
taking i_mutex. Now given that shared memory doesn't have disk
backing not doing anything in fsync seems fine and I left it out of
the vfs_fsync conversion for now, but in that case we might just
not pass it through to the lower file at all but just call the no-op
simple_sync_file directly.
[and now actually export vfs_fsync]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'include/crypto')
0 files changed, 0 insertions, 0 deletions