The commit is pushed to "branch-rh7-3.10.0-327.36.1.vz7.20.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-327.36.1.vz7.20.7
------>
commit 9021a6d2234ad9e6b175e05286d9dc0018c19a85
Author: Maxim Patlasov <mpatla...@virtuozzo.com>
Date: Wed Nov 30 15:34:35 2016 +0400
fuse: relax i_mutex coverage in fuse_fsync
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 796638a..d11125f 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -704,6 +704,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;
@@ -722,6 +724,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
