[Devel,RHEL7,COMMIT] fuse: relax i_mutex coverage in fuse_fsync

Submitted by Konstantin Khorenko on Nov. 30, 2016, 11:34 a.m.

Details

Message ID 201611301134.uAUBYaG3001180@finist_cl7.x64_64.work.ct
State New
Series "fuse: relax i_mutex coverage in fuse_fsync"
Headers show

Commit Message

Konstantin Khorenko Nov. 30, 2016, 11:34 a.m.
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 <mpatlasov@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 <mpatlasov@virtuozzo.com>
---
 fs/fuse/file.c | 3 +++
 1 file changed, 3 insertions(+)

Patch hide | download patch | download mbox

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;

Comments

Konstantin Khorenko Dec. 7, 2016, 2:57 p.m.
Please consider to RK.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 11/30/2016 02:34 PM, Konstantin Khorenko wrote:
> 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 <mpatlasov@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 <mpatlasov@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;
> .
>