Creating a hard link is required by POSIX to update the file ctime, so
ensure that the file data is synced to disk so that we don't clobber the
updated ctime by writing back after creating the hard link.

Fixes: 9f768272 ("NFS: Move the delegation return down into nfs4_proc_link()")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Storing the 'struct cred *' in nfs_access_entry is problematic.
An active 'cred' can keep a 'struct key *' active, and a quota is
imposed on the number of such keys that a user can maintain.
Cached 'nfs_access_entry' structs have indefinite lifetime, and having
these keep 'struct key's alive imposes on that quota.

So remove the 'struct cred *' and replace it with the fields we need:
  kuid_t, kgid_t, and struct group_info *

This makes the 'struct nfs_access_entry' 64 bits larger.

New function "access_cmp" is introduced which is identical to
cred_fscmp() except that the second arg is an 'nfs_access_entry', rather
than a 'cred'

Fixes: b68572e0 ("NFS: change access cache to use 'struct cred'.")
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Storing the 'struct cred *' in nfs_access_entry is problematic.
An active 'cred' can keep a 'struct key *' active, and a quota is
imposed on the number of such keys that a user can maintain.
Cached 'nfs_access_entry' structs have indefinite lifetime, and having
these keep 'struct key's alive imposes on that quota.

So a future patch will remove the ->cred ref from nfs_access_entry.

To prepare, change various functions to not assume there is a 'cred' in
the nfs_access_entry, but to pass the cred around explicitly.
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Currently the nfs_access_get_cached family of functions report a
'struct nfs_access_entry' as the result, with both .mask and .cred set.
However the .cred is never used.  This is probably good and there is no
guarantee that it won't be freed before use.

Change to only report the 'mask' - as this is all that is used or needed.
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

Pull the label from the fattr instead.
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

And usethe fattr's label field instead. I also adjust function calls to
remove labels along the way.
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

And instead allocate the fattr using nfs_alloc_fattr_with_label()
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

If fhandle is NULL or fattr is NULL, then 'error' is uninitialised.
Reported-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>

The original premise in commit 83672d39 ("NFS: Fix directory caching
problem - with test case and patch.") was that readdirplus was caching
attribute information and replaying it later. This is no longer the
case.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

If the directory changed while we were revalidating the dentry, then
don't update the dentry verifier. There is no value in setting the
verifier to an older value, and we could end up overwriting a more up to
date verifier from a parallel revalidation.

Fixes: efeda80d ("NFSv4: Fix revalidation of dentries with delegations")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>

If a user is doing 'ls -l', we have a heuristic in GETATTR that tells
the readdir code to try to use READDIRPLUS in order to refresh the inode
attributes. In certain cirumstances, we also try to invalidate the
remaining directory entries in order to ensure this refresh.

If there are multiple readers of the directory, we probably should avoid
invalidating the page cache, since the heuristic breaks down in that
situation anyway.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>

The check for duplicate readdir cookies should only care if the change
attribute is invalid or the data cache is invalid.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>

If we want to revalidate the directory, then just mark the change
attribute as invalid.

Fixes: 13c0b082 ("NFS: Replace use of NFS_INO_REVAL_PAGECACHE when checking cache validity")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>

After the success of an operation such as rmdir() or unlink(), we expect
to add the dentry back to the dcache as an ordinary negative dentry.
However in NFS, unless it is labelled with the appropriate verifier for
the parent directory state, then nfs_lookup_revalidate will end up
discarding that dentry and forcing a new lookup.

The fix is to ensure that we relabel the dentry appropriately on
success.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

After the success of an operation such as link(), or symlink(), we
expect to add the dentry back to the dcache as an ordinary positive
dentry.
However in NFS, unless it is labelled with the appropriate verifier for
the parent directory state, then nfs_lookup_revalidate will end up
discarding that dentry and forcing a new lookup.

The fix is to ensure that we relabel the dentry appropriately on
success.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

The section "19) Editor modelines and other cruft" in
Documentation/process/coding-style.rst clearly says, "Do not include any
of these in source files."

I recently receive a patch to explicitly add a new one.

Let's do treewide cleanups, otherwise some people follow the existing code
and attempt to upstream their favoriate editor setups.

It is even nicer if scripts/checkpatch.pl can check it.

If we like to impose coding style in an editor-independent manner, I think
editorconfig (patch [1]) is a saner solution.

[1] https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/

Link: https://lkml.kernel.org/r/20210324054457.1477489-1-masahiroy@kernel.orgSigned-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>	[auxdisplay]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

chown()/chgrp() and chmod() are separate operations, and in addition,
there are mode operations that are performed automatically by the
server. So let's track mode validity separately from the file ownership
validity.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

Rename can cause us to revalidate the access cache, so lets track the
nlinks separately from the mode/uid/gid.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

Add an argument to nfs_revalidate_inode() to allow callers to specify
which attributes they need to check for validity.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

The cached NFSv3/v4 readdir cookies are associated with a verifier,
which is checked by the server on subsequent calls to readdir, and is
only expected to change when the cookies (and hence also the page cache
contents) are considered invalid.
We therefore do have to store the verifier, but only when the page cache
is empty.

Fixes: b593c09f ("NFS: Improve handling of directory verifiers")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

If we're doing uncached readdir(), then the readdir cookie could be
different from the one cached in the nfs_inode. We should therefore
ensure that we save that one in the struct nfs_open_dir_context.

Fixes: 35df59d3 ("NFS: Reduce number of RPC calls when doing uncached readdir")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

If the loop in nfs_readdir_xdr_to_array() runs more than once, subsequent
READDIR RPCs may wrongly carry a zero cookie verifier and non-zero cookie.
Make sure subsequent calls to READDIR carry the cookie verifier returned
by the first call.
Signed-off-by: NNagendra S Tomar <natomar@microsoft.com>
Fixes: b593c09f ("NFS: Improve handling of directory verifiers")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>

nfs_set_cache_invalid() has code to handle delegations, and other
optimisations, so let's use it when appropriate.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

The fact that the lookup revalidation failed, does not mean that the
inode contents have changed.

Fixes: 5ceb9d7f ("NFS: Refactor nfs_lookup_revalidate()")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

There should be no reason to expect the directory permissions to change
just because the directory contents changed or a negative lookup timed
out. So let's avoid doing a full call to nfs_mark_for_revalidate() in
that case.
Furthermore, if this is a negative dentry, and we haven't actually done
a new lookup, then we have no reason yet to believe the directory has
changed at all. So let's remove the gratuitous directory inode
invalidation altogether when called from
nfs_lookup_revalidate_negative().
Reported-by: NGeert Jansen <gerardu@amazon.com>
Fixes: 5ceb9d7f ("NFS: Refactor nfs_lookup_revalidate()")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Extend some inode methods with an additional user namespace argument. A
filesystem that is aware of idmapped mounts will receive the user
namespace the mount has been marked with. This can be used for
additional permission checking and also to enable filesystems to
translate between uids and gids if they need to. We have implemented all
relevant helpers in earlier patches.

As requested we simply extend the exisiting inode method instead of
introducing new ones. This is a little more code churn but it's mostly
mechanical and doesnt't leave us with additional inode methods.

Link: https://lore.kernel.org/r/20210121131959.646623-25-christian.brauner@ubuntu.com
Cc: Christoph Hellwig <hch@lst.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>

The two helpers inode_permission() and generic_permission() are used by
the vfs to perform basic permission checking by verifying that the
caller is privileged over an inode. In order to handle idmapped mounts
we extend the two helpers with an additional user namespace argument.
On idmapped mounts the two helpers will make sure to map the inode
according to the mount's user namespace and then peform identical
permission checks to inode_permission() and generic_permission(). If the
initial user namespace is passed nothing changes so non-idmapped mounts
will see identical behavior as before.

Link: https://lore.kernel.org/r/20210121131959.646623-6-christian.brauner@ubuntu.com
Cc: Christoph Hellwig <hch@lst.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
Acked-by: NSerge Hallyn <serge@hallyn.com>
Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>

If the directory is changing, causing the page cache to get invalidated
while we are listing the contents, then the NFS client is currently forced
to read in the entire directory contents from scratch, because it needs
to perform a linear search for the readdir cookie. While this is not
an issue for small directories, it does not scale to directories with
millions of entries.
In order to be able to deal with large directories that are changing,
add a heuristic to ensure that if the page cache is empty, and we are
searching for a cookie that is not the zero cookie, we just default to
performing uncached readdir.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>

If we're doing uncached readdir, allocate multiple pages in order to
try to avoid duplicate RPC calls for the same getdents() call.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>

If the server is handing out monotonically increasing readdir cookie values,
then we can optimise away searches through pages that contain cookies that
lie outside our search range.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>

If the server insists on using the readdir verifiers in order to allow
cookies to expire, then we should ensure that we cache the verifier
with the cookie, so that we can return an error if the application
tries to use the expired cookie.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>

If the server returns NFS4ERR_NOT_SAME or tells us that the cookie is
bad in response to a READDIR call, then we should empty the page cache
so that we can fill it from scratch again.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>

If we're ever going to allow support for servers that use the readdir
verifier, then that use needs to be managed by the middle layers as
those need to be able to reject cookies from other verifiers.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>

Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NBenjamin Coddington <bcodding@redhat.com>
Tested-by: NDave Wysochanski <dwysocha@redhat.com>