On 11/30/2016 04:02 AM, Maxim Patlasov wrote: > 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> Can you pls think about merging the same into PCS6-Up12?
> --- > 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
