2011/2/22 Pavel Shilovsky <piastry@xxxxxxxxxxx>:
> We should invalidate a page even if it is locked now by someone, because
> we can leave an invalid data there and then think it's uptodate according
> to an oplock level (exclusive or II).
>
> Signed-off-by: Pavel Shilovsky <piastry@xxxxxxxxxxx>
> ---
> fs/cifs/inode.c | 13 ++++++++-----
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index 8852470..1da1f26 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1691,12 +1691,15 @@ cifs_invalidate_mapping(struct inode *inode)
>
> cifs_i->invalid_mapping = false;
>
> - /* write back any cached data */
> - if (inode->i_mapping && inode->i_mapping->nrpages != 0) {
> - rc = filemap_write_and_wait(inode->i_mapping);
> - mapping_set_error(inode->i_mapping, rc);
> + if (inode->i_mapping) {
> + /* write back any cached data */
> + if (inode->i_mapping->nrpages != 0) {
> + rc = filemap_write_and_wait(inode->i_mapping);
> + mapping_set_error(inode->i_mapping, rc);
> + }
> + invalidate_inode_pages2(inode->i_mapping);
> }
> - invalidate_remote_inode(inode);
> +
> cifs_fscache_reset_inode_cookie(inode);
> }
>
> --
> 1.7.1
>
>
After investigating some more time, I found out that at least the
description of this patch isn't valid. Let's drop this one.
The problem is that we use invalidate_remote_inode that don't think
about return value from invalidate_mapping_pages and return void. The
problem is that invalidate_mapping_pages return 0 instead of positive
value. I will continue investigation of this problem.
--
Best regards,
Pavel Shilovsky.
--
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
