From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, Christian Brauner <brauner@kernel.org>
Subject: [git pull][6.17] vfs.git 1/9: d_flags pile
Date: Sat, 26 Jul 2025 09:01:19 +0100 [thread overview]
Message-ID: <20250726080119.GA222315@ZenIV> (raw)
[trivial conflict in Documentation/filesystems/porting.rst]
The following changes since commit 19272b37aa4f83ca52bdf9c16d5d81bdd1354494:
Linux 6.16-rc1 (2025-06-08 13:44:43 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-dcache
for you to fetch changes up to a509e7cf622bc7ce3f45b1c7047fc2a5e9bea869:
configfs: use DCACHE_DONTCACHE (2025-06-11 13:41:05 -0400)
----------------------------------------------------------------
Current exclusion rules for ->d_flags stores are rather unpleasant.
The basic rules are simple:
* stores to dentry->d_flags are OK under dentry->d_lock.
* stores to dentry->d_flags are OK in the dentry constructor, before
becomes potentially visible to other threads.
Unfortunately, there's a couple of exceptions to that, and that's where the
headache comes from.
Main PITA comes from d_set_d_op(); that primitive sets ->d_op
of dentry and adjusts the flags that correspond to presence of individual
methods. It's very easy to misuse; existing uses _are_ safe, but proof
of correctness is brittle.
Use in __d_alloc() is safe (we are within a constructor), but we
might as well precalculate the initial value of ->d_flags when we set
the default ->d_op for given superblock and set ->d_flags directly
instead of messing with that helper.
The reasons why other uses are safe are bloody convoluted; I'm not going
to reproduce it here. See https://lore.kernel.org/all/20250224010624.GT1977892@ZenIV/
for gory details, if you care. The critical part is using d_set_d_op() only
just prior to d_splice_alias(), which makes a combination of d_splice_alias()
with setting ->d_op, etc. a natural replacement primitive. Better yet, if
we go that way, it's easy to take setting ->d_op and modifying ->d_flags
under ->d_lock, which eliminates the headache as far as ->d_flags exclusion
rules are concerned. Other exceptions are minor and easy to deal with.
What this series does:
* d_set_d_op() is no longer available; new primitive (d_splice_alias_ops())
is provided, equivalent to combination of d_set_d_op() and d_splice_alias().
* new field of struct super_block - ->s_d_flags. Default value of ->d_flags
to be used when allocating dentries on this filesystem.
* new primitive for setting ->s_d_op: set_default_d_op(). Replaces stores
to ->s_d_op at mount time. All in-tree filesystems converted; out-of-tree
ones will get caught by compiler (->s_d_op is renamed, so stores to it will
be caught). ->s_d_flags is set by the same primitive to match the ->s_d_op.
* a lot of filesystems had ->s_d_op->d_delete equal to always_delete_dentry;
that is equivalent to setting DCACHE_DONTCACHE in ->d_flags, so such filesystems
can bloody well set that bit in ->s_d_flags and drop ->d_delete() from
dentry_operations. In quite a few cases that results in empty dentry_operations,
which means that we can get rid of those.
* kill simple_dentry_operations - not needed anymore.
* massage d_alloc_parallel() to get rid of the other exception wrt ->d_flags
stores - we can set DCACHE_PAR_LOOKUP as soon as we allocate the new dentry;
no need to delay that until we commit to using the sucker.
As the result, ->d_flags stores are all either under ->d_lock or done before
the dentry becomes visible in any shared data structures.
----------------------------------------------------------------
Al Viro (20):
d_set_mounted(): we don't need to bump seqcount component of rename_lock
procfs: kill ->proc_dops
new helper: d_splice_alias_ops()
switch procfs from d_set_d_op() to d_splice_alias_ops()
fuse: no need for special dentry_operations for root dentry
new helper: set_default_d_op()
split d_flags calculation out of d_set_d_op()
correct the set of flags forbidden at d_set_d_op() time
set_default_d_op(): calculate the matching value for ->d_flags
simple_lookup(): just set DCACHE_DONTCACHE
make d_set_d_op() static
d_alloc_parallel(): set DCACHE_PAR_LOOKUP earlier
shmem: no dentry retention past the refcount reaching zero
devpts, sunrpc, hostfs: don't bother with ->d_op
kill simple_dentry_operations
ramfs, hugetlbfs, mqueue: set DCACHE_DONTCACHE
9p: don't bother with always_delete_dentry
efivarfs: use DCACHE_DONTCACHE instead of always_delete_dentry()
debugfs: use DCACHE_DONTCACHE
configfs: use DCACHE_DONTCACHE
Steven Rostedt (1):
tracefs: Add d_delete to remove negative dentries
Documentation/filesystems/porting.rst | 18 ++++
fs/9p/vfs_dentry.c | 1 -
fs/9p/vfs_super.c | 10 ++-
fs/adfs/super.c | 2 +-
fs/affs/super.c | 4 +-
fs/afs/super.c | 4 +-
fs/autofs/inode.c | 2 +-
fs/btrfs/super.c | 2 +-
fs/ceph/super.c | 2 +-
fs/coda/inode.c | 2 +-
fs/configfs/dir.c | 1 -
fs/configfs/mount.c | 3 +-
fs/dcache.c | 153 ++++++++++++++++++++--------------
fs/debugfs/inode.c | 4 +-
fs/devpts/inode.c | 2 +-
fs/ecryptfs/main.c | 2 +-
fs/efivarfs/super.c | 4 +-
fs/exfat/super.c | 4 +-
fs/fat/namei_msdos.c | 2 +-
fs/fat/namei_vfat.c | 4 +-
fs/fuse/dir.c | 7 --
fs/fuse/fuse_i.h | 1 -
fs/fuse/inode.c | 6 +-
fs/gfs2/ops_fstype.c | 2 +-
fs/hfs/super.c | 2 +-
fs/hfsplus/super.c | 2 +-
fs/hostfs/hostfs_kern.c | 2 +-
fs/hpfs/super.c | 2 +-
fs/hugetlbfs/inode.c | 1 +
fs/isofs/inode.c | 2 +-
fs/jfs/super.c | 2 +-
fs/kernfs/mount.c | 2 +-
fs/libfs.c | 27 +++---
fs/nfs/super.c | 2 +-
fs/ntfs3/super.c | 3 +-
fs/ocfs2/super.c | 2 +-
fs/orangefs/super.c | 2 +-
fs/overlayfs/super.c | 2 +-
fs/proc/base.c | 9 +-
fs/proc/generic.c | 10 ++-
fs/proc/internal.h | 6 +-
fs/proc/namespaces.c | 3 +-
fs/proc/proc_sysctl.c | 7 +-
fs/ramfs/inode.c | 1 +
fs/smb/client/cifsfs.c | 4 +-
fs/tracefs/inode.c | 13 ++-
fs/vboxsf/super.c | 2 +-
include/linux/dcache.h | 6 +-
include/linux/fs.h | 4 +-
include/linux/proc_fs.h | 2 +
ipc/mqueue.c | 1 +
mm/shmem.c | 4 +-
net/sunrpc/rpc_pipe.c | 2 +-
53 files changed, 210 insertions(+), 159 deletions(-)
next reply other threads:[~2025-07-26 8:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-26 8:01 Al Viro [this message]
2025-07-26 8:02 ` [git pull][6.17] vfs.git 2/9: simple_recursive_removal Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:03 ` [git pull][6.17] vfs.git 3/9: rpc_pipefs Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:04 ` [git pull][6.17] vfs.git 4/9: asm/param.h pile Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:05 ` [git pull][6.17] vfs.git 5/9: securityfs Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:05 ` [git pull][6.17] vfs.git 6/9: misc pile Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:08 ` [git pull][6.17] vfs.git 7/9: ceph d_name fixes Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:08 ` [git pull][6.17] vfs.git 8/9: CLASS(fd) followup Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-26 8:09 ` [git pull][6.17] vfs.git 9/9: mount pile Al Viro
2025-07-28 23:41 ` pr-tracker-bot
2025-07-28 23:41 ` [git pull][6.17] vfs.git 1/9: d_flags pile pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250726080119.GA222315@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox