All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)

             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.