fuse_fsync_common() does need i_mutex for fuse_sync_writes() and fuse_flush_mtime(). But when those operations are done, it's actually doesn't matter whether to hold the lock over fuse_request_send(FUSE_FSYNC) or not: we ensured that all relevant data were already seen by userspace fuse daemon, and so it will sync them (by handling FUSE_FSYNC) anyway; if the user screws up by leaking new data updates in-between, it is up to the user and doesn't violate fsync(2) semantics.
https://jira.sw.ru/browse/PSBM-55919 Signed-off-by: Maxim Patlasov <mpatla...@virtuozzo.com> --- fs/fuse/file.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 464b2f5..559dfd9 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -697,6 +697,8 @@ int fuse_fsync_common(struct file *file, loff_t start, loff_t end, goto out; } + mutex_unlock(&inode->i_mutex); + memset(&inarg, 0, sizeof(inarg)); inarg.fh = ff->fh; inarg.fsync_flags = datasync ? 1 : 0; @@ -715,6 +717,7 @@ int fuse_fsync_common(struct file *file, loff_t start, loff_t end, fc->no_fsync = 1; err = 0; } + return err; out: mutex_unlock(&inode->i_mutex); return err; _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
