If necessary, the caches will get zapped under normal revalidation.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

LOOKUP returns the directory post-op attributes whether or not the
operation was successful.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Why bother, since the call to nfs4_atomic_open() will do it for us.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We don't need to call nfs_revalidate_inode() on the directory if we already
know that the verifiers don't match.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Otherwise set it to nfsi->read_cache_jiffies in order to prevent jiffy
wraparound issues.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The lower level routines in fs/nfs/proc.c, fs/nfs/nfs3proc.c and
fs/nfs/nfs4proc.c should already be dealing with the revalidation issues.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We have no more users...
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The fact that we're in the process of modifying the inode does not mean
that we should not invalidate the attribute and data caches. The defensive
thing is to always invalidate when we're confronted with inode
mtime/ctime or change_attribute updates that we do not immediately
recognise.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The parent of the newly materialised dentry has just been revalidated...
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

If the ->lookup() call causes the directory verifier to change, then there
is still no need to use the old verifier, since our dentry has been
verified.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Just let the subsequent inode revalidation do the update...
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

If nfs_post_op_update_inode fails because the server didn't return any
attributes, then we let the subsequent inode revalidation update
cache_change_attribute.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We only need to look at the mtime changes...
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The attribute revalidation code will already have taken care of resetting
nfsi->cache_change_attribute.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We want to set the verifier when the call to nfs4_open_revalidate()
_succeeds_.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We don't want to leave an unverified hashed negative dentry if the
exclusive create fails to complete.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

That will also allow us to remove the calls in mknod and mkdir.
In addition it will ensure that symlinks set it correctly.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Also ensure that it drops the dentry in this case.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We don't care about whether or not some other process on our client is
changing the directory while we're in nfs_lookup_revalidate(), because the
dcache will take care of ensuring local atomicity.
We can therefore remove the test for nfs_caches_unstable().
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Also fix up the comments.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

NFSv2 and v4 don't offer weak cache consistency attributes on WRITE calls.
In NFSv3, returning wcc data is optional. In all cases, we want to prevent
the client from invalidating our cached data whenever ->write_done()
attempts to update the inode attributes.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Remove the bogus 'data_stable' check in nfs_update_inode. The
cache_change_attribute tells you if the directory changed on the server,
and should have nothing to do with the file length.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

For one thing, the test NFS_ATTRTIMEO() == 0 makes no sense: we're
testing whether or not the cache timeout length is zero, which is totally
unrelated to the issue of whether or not we trust the file staleness.

Secondly, we do not want to retry the GETATTR once a file has been declared
stale by the server: we rather want to discard that inode as soon as
possible, since there are broken servers still in use out there that reuse
filehandles on new files.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

NFSv3 will correctly update atime on a read() call, so there is no need to
set the NFS_INO_INVALID_ATIME flag unless the call to nfs_refresh_inode()
fails.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

NFSv3 will correctly update atime on a readdir call, so there is no need to
set the NFS_INO_INVALID_ATIME flag unless the call to nfs_refresh_inode()
fails.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

In NFSv4 we should only be looking at the change attribute.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The reason is that if the weak cache consistency update was successful,
then we know that our client must be the only one that changed the
directory, and we've already updated the dcache to reflect the change.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We must ensure that the readdir data is always invalidated whether or not
the weak cache consistency data update succeeds.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We don't need to force a dentry lookup just because we're making changes to
the directory.

Don't update nfsi->cache_change_attribute in nfs_end_data_update: that
overrides the NFSv3/v4 weak consistency checking that tells us our update
was the only one, and that tells us the dcache is still valid.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We always want to check that the verifier and directory
cache_change_attribute match. This also allows us to remove the 'wraparound
hack' for the cache_change_attribute. If we're only checking for equality,
then we don't care about wraparound issues.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Ensure that we don't clobber the results from a more recent getattr call...
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

We should always be declaring the attribute cache as valid after having
updated it.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

It doesn't really make sense to cache an access call without also
revalidating the attributes.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Currently, _nfs4_do_access() is just a copy of nfs_do_access() with added
conversion of the open flags into an access mask. This patch merges the
duplicate functionality.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>