Hi,

This patch cleans up duplicate includes in
	include/linux/nfs_fs.h
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

This patch makes the needlessly global struct rpcb_program static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Use correct type signage in gss_krb5_remove_padding() when doing length
calculations.  Both xdr_buf.len and iov.iov_len are size_t, which is
unsigned; so use an unsigned type for our temporary length variable to
ensure we don't overflow it..
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Since 43780b87..., rpc_create() fills in a default hostname based on
the ip address if the servername passed in is null.  A small typo made
that default incorrect.  (But this information appears to be used only
for debugging right now, so I don't believe the typo causes any bugs in
the current kernel.)

Thanks to Olga Kornievskaia for bug report and testing.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Cc: Olga Kornievskaia <aglo@citi.umich.edu>
Cc: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

On the client, when an alternate server port is specified on the mount
commandline, we need to make sure gssd knows about it.

Also, on the server side, when we're sending krb5 callbacks to the
client, we'll use the same mechanism to let gssd know about the callback
port.

Thanks to Olga Kornievskaia for testing and for an earlier
implementation.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Cc: Olga Kornievskaia <aglo@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

- NFS_READTIME, NFS_CHANGE_ATTR are completely unused.
- Inline the few remaining uses of NFS_ATTRTIMEO, and remove.
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>

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

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>