kernel/linux.git/fs/ecryptfs/dentry.c, branch v6.18.21

ecryptfs: get rid of pointless mount references in ecryptfs dentries

2025-09-16T01:26:44+00:00

->lower_path.mnt has the same value for all dentries on given ecryptfs instance and if somebody goes for mountpoint-crossing variant where that would not be true, we can deal with that when it happens (and _not_ with duplicating these reference into each dentry). As it is, we are better off just sticking a reference into ecryptfs-private part of superblock and keeping it pinned until ->kill_sb(). That way we can stick a reference to underlying dentry right into ->d_fsdata of ecryptfs one, getting rid of indirection through struct ecryptfs_dentry_info, along with the entire struct ecryptfs_dentry_info machinery. [kudos to Dan Carpenter for spotting a bug in ecryptfs_get_tree() part] Reviewed-by: Christian Brauner Signed-off-by: Al Viro

Pass parent directory inode and expected name to ->d_revalidate()

2025-01-28T00:25:23+00:00

->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 Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Al Viro

ecryptfs: dentry: File headers are not good candidates for kernel-doc

2021-04-19T04:42:13+00:00

Fixes the following W=1 kernel build warning(s): fs/ecryptfs/dentry.c:19: warning: Incorrect use of kernel-doc format: * ecryptfs_d_revalidate - revalidate an ecryptfs dentry fs/ecryptfs/dentry.c:32: warning: Function parameter or member 'dentry' not described in 'ecryptfs_d_revalidate' fs/ecryptfs/dentry.c:32: warning: Function parameter or member 'flags' not described in 'ecryptfs_d_revalidate' fs/ecryptfs/dentry.c:32: warning: expecting prototype for eCryptfs(). Prototype was for ecryptfs_d_revalidate() instead Cc: Tyler Hicks Cc: "Michael A. Halcrow" Cc: ecryptfs@vger.kernel.org Signed-off-by: Lee Jones Signed-off-by: Tyler Hicks

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156

2019-05-30T18:26:35+00:00

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Richard Fontana Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman

eCryptfs: Invalidate dcache entries when lower i_nlink is zero

2015-08-18T22:29:48+00:00

Consider eCryptfs dcache entries to be stale when the corresponding lower inode's i_nlink count is zero. This solves a problem caused by the lower inode being directly modified, without going through the eCryptfs mount, leaving stale eCryptfs dentries cached and the eCryptfs inode's i_nlink count not being cleared. Signed-off-by: Tyler Hicks Reported-by: Richard Weinberger Cc: stable@vger.kernel.org

VFS: normal filesystems (and lustre): d_inode() annotations

2015-04-15T19:06:57+00:00

that's the bulk of filesystem drivers dealing with inodes of their own Signed-off-by: David Howells Signed-off-by: Al Viro

ecryptfs: ->lower_path.dentry is never NULL

2013-10-25T03:34:48+00:00

... on anything found via ->d_fsdata Signed-off-by: Al Viro

ecryptfs: don't leave RCU pathwalk immediately

2013-10-25T03:34:48+00:00

If the underlying dentry doesn't have ->d_revalidate(), there's no need to force dropping out of RCU mode. All we need for that is to make freeing ecryptfs_dentry_info RCU-delayed. Signed-off-by: Al Viro

ecryptfs: check DCACHE_OP_REVALIDATE instead of ->d_op

2013-10-25T03:34:47+00:00

Signed-off-by: Al Viro

eCryptfs: Fix -Wunused-but-set-variable warnings

2013-01-17T19:36:10+00:00

These two variables are no longer used and can be removed. Fixes warnings when building with W=1. Signed-off-by: Tyler Hicks