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? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
