Re: [PATCH, RFC] add a vfs_fsync helper

[Nick Piggin <npiggin@suse.de>]

On Mon, Dec 22, 2008 at 10:03:57AM +0100, Christoph Hellwig wrote:
> 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.

Seems like an improvement.. I've wanted to know, though, what do
we need i_mutex for? Is it just convention, or is there some good
reason to have it in generic code?