]> www.infradead.org Git - users/willy/pagecache.git/commit
Pass parent directory inode and expected name to ->d_revalidate()
authorAl Viro <viro@zeniv.linux.org.uk>
Sun, 8 Dec 2024 05:28:51 +0000 (00:28 -0500)
committerAl Viro <viro@zeniv.linux.org.uk>
Tue, 28 Jan 2025 00:25:23 +0000 (19:25 -0500)
commit5be1fa8abd7b049f51e6e98e75a37eef5ae2c296
tree8e76c9de05a8dd618fb68232bf99939df624b225
parent4c43ab1b100f95c410a8633d5a6eb9d74afb5b8d
Pass parent directory inode and expected name to ->d_revalidate()

->d_revalidate() often needs to access dentry parent and name; that has
to be done carefully, since the locking environment varies from caller
to caller.  We are not guaranteed that dentry in question will not be
moved right under us - not unless the filesystem is such that nothing
on it ever gets renamed.

It can be dealt with, but that results in boilerplate code that isn't
even needed - the callers normally have just found the dentry via dcache
lookup and want to verify that it's in the right place; they already
have the values of ->d_parent and ->d_name stable.  There is a couple
of exceptions (overlayfs and, to less extent, ecryptfs), but for the
majority of calls that song and dance is not needed at all.

It's easier to make ecryptfs and overlayfs find and pass those values if
there's a ->d_revalidate() instance to be called, rather than doing that
in the instances.

This commit only changes the calling conventions; making use of supplied
values is left to followups.

NOTE: some instances need more than just the parent - things like CIFS
may need to build an entire path from filesystem root, so they need
more precautions than the usual boilerplate.  This series doesn't
do anything to that need - these filesystems have to keep their locking
mechanisms (rename_lock loops, use of dentry_path_raw(), private rwsem
a-la v9fs).

One thing to keep in mind when using name is that name->name will normally
point into the pathname being resolved; the filename in question occupies
name->len bytes starting at name->name, and there is NUL somewhere after it,
but it the next byte might very well be '/' rather than '\0'.  Do not
ignore name->len.

Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Gabriel Krisman Bertazi <gabriel@krisman.be>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
30 files changed:
Documentation/filesystems/locking.rst
Documentation/filesystems/porting.rst
Documentation/filesystems/vfs.rst
fs/9p/vfs_dentry.c
fs/afs/dir.c
fs/ceph/dir.c
fs/coda/dir.c
fs/crypto/fname.c
fs/ecryptfs/dentry.c
fs/exfat/namei.c
fs/fat/namei_vfat.c
fs/fuse/dir.c
fs/gfs2/dentry.c
fs/hfs/sysdep.c
fs/jfs/namei.c
fs/kernfs/dir.c
fs/namei.c
fs/nfs/dir.c
fs/ocfs2/dcache.c
fs/orangefs/dcache.c
fs/overlayfs/super.c
fs/proc/base.c
fs/proc/fd.c
fs/proc/generic.c
fs/proc/proc_sysctl.c
fs/smb/client/dir.c
fs/tracefs/inode.c
fs/vboxsf/dir.c
include/linux/dcache.h
include/linux/fscrypt.h