linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: Amir Goldstein <amir73il@gmail.com>,
	Christoph Hellwig <hch@lst.de>, Tyler Hicks <code@tyhicks.com>,
	David Howells <dhowells@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	ecryptfs@vger.kernel.org, linux-cachefs@redhat.com,
	Christian Brauner <christian.brauner@ubuntu.com>
Subject: [PATCH 0/7] fs: tweak and switch more fses to private mounts
Date: Wed, 14 Apr 2021 14:37:44 +0200	[thread overview]
Message-ID: <20210414123750.2110159-1-brauner@kernel.org> (raw)

From: Christian Brauner <christian.brauner@ubuntu.com>

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
-- 
2.27.0


             reply	other threads:[~2021-04-14 12:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 12:37 Christian Brauner [this message]
2021-04-14 12:37 ` [PATCH 1/7] namespace: fix clone_private_mount() kernel doc Christian Brauner
2021-04-14 12:37 ` [PATCH 2/7] namespace: add kernel doc for mnt_clone_internal() Christian Brauner
2021-04-14 12:37 ` [PATCH 3/7] namespace: move unbindable check out of clone_private_mount() Christian Brauner
2021-04-14 12:37 ` [PATCH 4/7] cachefiles: switch to using a private mount Christian Brauner
2021-04-14 12:37 ` [PATCH 5/7] cachefiles: extend ro check to " Christian Brauner
2021-04-14 12:37 ` [PATCH 6/7] ecryptfs: switch to using a " Christian Brauner
2021-04-19  5:01   ` Tyler Hicks
2021-04-22 20:46     ` Tyler Hicks
2021-04-14 12:37 ` [PATCH 7/7] ecryptfs: extend ro check to " Christian Brauner

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=20210414123750.2110159-1-brauner@kernel.org \
    --to=brauner@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=code@tyhicks.com \
    --cc=dhowells@redhat.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).