On Sun, 28 Nov 2010 11:12:50 +0300
Pavel Shilovsky <[email protected]> wrote:

> Remove filemap_write_and_wait call because it is previously called from
> vfs_sync_range and invalidate inode if we don't have at least Level II
> oplock and strcit cache mode switched on.
> 

I think you mean vfs_fsync_range?

> Signed-off-by: Pavel Shilovsky <[email protected]>
> ---
>  fs/cifs/file.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index f853bf0..22d0421 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -1595,20 +1595,20 @@ int cifs_fsync(struct file *file, int datasync)
>       struct cifsTconInfo *tcon;
>       struct cifsFileInfo *smbfile = file->private_data;
>       struct inode *inode = file->f_path.dentry->d_inode;
> +     struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
>  
>       xid = GetXid();
>  
>       cFYI(1, "Sync file - name: %s datasync: 0x%x",
>               file->f_path.dentry->d_name.name, datasync);
>  
> -     rc = filemap_write_and_wait(inode->i_mapping);
> -     if (rc == 0) {
> -             struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
> +     if (!CIFS_I(inode)->clientCanCacheRead &&
> +         (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_STRICT_IO))
> +             invalidate_remote_inode(inode);
>  
> -             tcon = tlink_tcon(smbfile->tlink);
> -             if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOSSYNC))
> -                     rc = CIFSSMBFlush(xid, tcon, smbfile->netfid);
> -     }
> +     tcon = tlink_tcon(smbfile->tlink);
> +     if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOSSYNC))
> +             rc = CIFSSMBFlush(xid, tcon, smbfile->netfid);
>  
>       FreeXid(xid);
>       return rc;


Looks reasonable. I like the fact that we're pulling out the
unnecessary filemap_write_and_wait here.

Reviewed-by: Jeff Layton <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to