From: Christian Brauner <christian@brauner.io>
To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: torvalds@linux-foundation.org, tglx@linutronix.de,
kstewart@linuxfoundation.org, gregkh@linuxfoundation.org,
pombredanne@nexb.com, linux-api@vger.kernel.org,
ebiederm@xmission.com, seth.forshee@canonical.com,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH 0/6 v1 resend] statfs: handle mount propagation
Date: Wed, 13 Jun 2018 16:06:25 +0200 [thread overview]
Message-ID: <20180613140625.GA31082@mailbox.org> (raw)
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
On Fri, May 25, 2018 at 02:48:19PM +0200, Christian Brauner wrote:
> From: Christian Brauner <christian.brauner@ubuntu.com>
>
> Hey,
>
> This is v1 of this patchset. All changes from v0 to v1 are non-functional.
> Specifically, the commit messages and justification have been extended as
> requested by Linus and Al.
Hey everyone,
Just a ping whether the requested changes have made this series suitable
for inclusion. Would be excellent if someone could do another review. :)
Thanks!
Christian
>
> This little series does the following:
>
> - unify the definition of constants in statfs.h and fs.h:
> The definitions for MS_* flags are currently a mixture between hex values
> and bit-shifts. All higher values are already initialized with bit-shifts
> for MS_* constants starting with (1<<16). This patch switches the
> definitions for MS_* constants over to uniformly use bit-shifts and
> alignes the definitions of ST_* flags too.
> Initializing them identically let's userspace easily detect when flags
> indicate the same property but use a different value in doing so.
>
> - extend statfs to handle mount propagation:
> For all cases the only way to do this right now is by parsing
> /proc/<pid>/mountinfo. Yes, it is doable but still it is somewhat costly
> and annoying as e.g. those mount propagation fields are optional.
> 1. prevent propagation from happening:
> From a userspace perspective we often run into the case where we
> simply want to know whether a given mountpoint is MS_SHARED or is
> MS_SLAVE. If it is we remount it as MS_PRIVATE to prevent any
> propagation from happening. We don't care about the peer
> relationship or how the propagation is exactly setup. We only want
> to prevent any propagation from happening.
> These mountpoints might be known in advance so parsing
> /proc/<pid>/mountinfo should not be needed.
> 2. differentiate between MS_SLAVE and MS_SHARED mountpoints:
> Mountpoints that are MS_SLAVE are kept intact and mountpoints that
> are MS_SHARED are made MS_PRIVATE. These mountpoint might be known in
> advance so parsing /proc/<pid>/mountinfo should not be needed.
> 3. retrieve propagation properties when procfs is not mounted:
> When the set of interesting mountpoints is known and /proc is not
> mounted calling statfs() is the only good way to reliably determine
> the propagation property of a mountpoint.
> 4. inspecting file descriptors to mountpoints for propagation
> properties:
> When file descriptors to mountpoints are passed around between
> processes it is useful to have fstatvfs() handle mount propagation
> properties too.
> To this end the flags:
> - ST_UNBINDABLE
> - ST_SHARED
> - ST_PRIVATE
> - ST_SLAVE
> are added. They have the same value as their MS_* counterparts.
>
> - Testing:
> I verified that now userspace can do e.g.
>
> int ret;
> char *s = "/some/path";
> struct statvfs sb;
>
> ret = statvfs(s, &sb);
> if (ret < 0)
> return false;
>
> if (sb.f_flag & ST_SHARED) {
> ret = mount("", s, NULL, MS_SLAVE | MS_REC, NULL);
> if (ret < 0)
> return -1;
> }
>
> Thanks!
> Christian
>
> Christian Brauner (6):
> fs: use << for MS_* flags
> statfs: use << to align with fs header
> statfs: add ST_UNBINDABLE
> statfs: add ST_SHARED
> statfs: add ST_SLAVE
> statfs: add ST_PRIVATE
>
> fs/statfs.c | 16 +++++++++++++++-
> include/linux/statfs.h | 30 +++++++++++++++++-------------
> include/uapi/linux/fs.h | 33 +++++++++++++++++----------------
> 3 files changed, 49 insertions(+), 30 deletions(-)
>
> --
> 2.17.0
>
next prev parent reply other threads:[~2018-06-13 14:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 12:48 [PATCH 0/6 v1 resend] statfs: handle mount propagation Christian Brauner
2018-05-25 12:48 ` [PATCH 1/6 v1 resend] fs: use << for MS_* flags Christian Brauner
2018-05-25 12:48 ` [PATCH 2/6 v1 resend] statfs: use << to align with fs header Christian Brauner
2018-05-25 12:48 ` [PATCH 3/6 v1 resend] statfs: add ST_UNBINDABLE Christian Brauner
2018-05-25 12:48 ` [PATCH 4/6 v1 resend] statfs: add ST_SHARED Christian Brauner
2018-05-25 12:48 ` [PATCH 5/6 v1 resend] statfs: add ST_SLAVE Christian Brauner
2018-05-25 12:48 ` [PATCH 6/6 v1 resend] statfs: add ST_PRIVATE Christian Brauner
2018-06-13 14:06 ` Christian Brauner [this message]
2018-06-13 14:24 ` [PATCH 0/6 v1 resend] statfs: handle mount propagation Greg KH
2018-06-13 15:07 ` Christian Brauner
2018-07-19 15:30 ` 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=20180613140625.GA31082@mailbox.org \
--to=christian@brauner.io \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pombredanne@nexb.com \
--cc=seth.forshee@canonical.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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 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.