On Sun, 31 Oct 2010 22:42:40 +0300 Pavel Shilovsky <piastryyy@xxxxxxxxx> 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 <piastryyy@xxxxxxxxx> > --- > 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 <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
