On Sun, 31 Oct 2010 22:42:40 +0300
Pavel Shilovsky <[email protected]> wrote:

> When we close the last file handle of the inode we should invalidate it
> to prevent data coherency problem when we open it again but it has been
> modified by other clients.
> 
> Signed-off-by: Pavel Shilovsky <[email protected]>
> ---
>  fs/cifs/file.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index d7c212a..6edeb5b 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -290,6 +290,8 @@ void cifsFileInfo_put(struct cifsFileInfo *cifs_file)
>                       cifs_file->dentry->d_inode);
>               cifsi->clientCanCacheRead = false;
>               cifsi->clientCanCacheAll  = false;
> +             if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_STRICT_IO)
> +                     invalidate_remote_inode(inode);
>       }
>       spin_unlock(&cifs_file_list_lock);
> 

NAK. I don't think it's safe to call invalidate_remote_inode under a
spinlock like this.

-- 
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