Skip to content

fs: tweak and switch more fses to private mounts

Christian Brauner ecryptfs linux-fsdevel 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest7 patches 2 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/7namespace: fix clone_private_mount() kernel docfs/namespace.c+13 -40 replies
2/7namespace: add kernel doc for mnt_clone_internal()fs/namespace.c+16 -00 replies
3/7namespace: move unbindable check out of clone_private_mount()fs/namespace.c fs/overlayfs/super.c+11 -50 replies
4/7cachefiles: switch to using a private mountfs/cachefiles/bind.c+24 -100 replies
5/7cachefiles: extend ro check to private mountfs/cachefiles/bind.c+6 -10 replies
6/7ecryptfs: switch to using a private mountfs/ecryptfs/dentry.c fs/ecryptfs/ecryptfs_kernel.h fs/ecryptfs/inode.c +1 more+42 -72 replies
7/7ecryptfs: extend ro check to private mountfs/ecryptfs/main.c+1 -10 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/7] fs: tweak and switch more fses to private mounts

From: Christian Brauner <[email protected]>

Hey,

Since [1] we support creating private mounts from a given path's vfsmount. This makes them very suitable for any filesystem or filesystem functionality that piggybacks on paths of another filesystem. Overlayfs, cachefiles, and ecryptfs are three prime examples.

Since private mounts aren't attached in the filesystem they aren't affected by mount property changes after the respective fs makes use of them. This seems a rather desirable property as the underlying path can't e.g. suddenly go from read-write to read-only and in general it means that the fs is always in full control of the underlying mount after the user has allowed it to be used (apart from operations that affect the superblock of course).

Besides that it also makes things simpler for a variety of other vfs features. One concrete example is fanotify. When the path->mnt of the path that is used as a cache has been marked with FAN_MARK_MOUNT the semantics get tricky as it isn't clear whether the watchers of path->mnt should get notified about fsnotify events when files are created by ecryptfs via path->mnt. Using a private mount lets us handle this case too and aligns the behavior of stacks created by overlayfs.

Thanks!
Christian

[1]: c771d683a62e ("vfs: introduce clone_private_mount()")

Christian Brauner (7):
namespace: fix clone_private_mount() kernel doc
namespace: add kernel doc for mnt_clone_internal()
namespace: move unbindable check out of clone_private_mount()
cachefiles: switch to using a private mount
cachefiles: extend ro check to private mount
ecryptfs: switch to using a private mount
ecryptfs: extend ro check to private mount

 fs/cachefiles/bind.c          | 41 +++++++++++++++++++++++++----------
 fs/ecryptfs/dentry.c          |  6 ++++-
 fs/ecryptfs/ecryptfs_kernel.h |  9 ++++++++
 fs/ecryptfs/inode.c           |  5 ++++-
 fs/ecryptfs/main.c            | 31 +++++++++++++++++++++-----
 fs/namespace.c                | 36 ++++++++++++++++++++++++------
 fs/overlayfs/super.c          | 13 +++++++++--
 7 files changed, 113 insertions(+), 28 deletions(-)

base-commit: e49d033bddf5b565044e2abe4241353959bc9120

Signature · 1 line
2.27.0