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>

nfs_set_verifier() and nfs_refresh_verifier() do exactly the same thing, so
replace one with the other.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The nfs_renew_times() function plants the current time in jiffies in
dentry->d_time.  But a call to nfs_renew_times() is always followed by
another call that overwrites dentry->d_time.  Get rid of the
nfs_renew_times() calls.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Negative dentries need to be reverified after an asynchronous unlink.

Quoth Trond:

"Unfortunately I don't think that we can avoid revalidating the
resulting negative dentry since the UNLINK call is asynchronous,
and so the new verifier on the directory will only be known a
posteriori."
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

NFS performance metrics reported zero bytes sent per op when mounting with
UDP.  The UDP socket transport wasn't properly counting the number of bytes
sent.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The default "intr" setting is different for NFS and NFSv4.  To avoid
confusion on this issue, don't hide the "nointr" option in /proc/mounts.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Re-order mount option sanity checking slightly to ensure we have a valid
server address *before* trying to do the mountd RPC call.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Add a dependency on RDMA before enabling SUNRPC_XPRT_RDMA
Yes, "INFINIBAND" also turns on iWARP and other RDMA support.
Signed-off-by: NTom Talpey <talpey@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>