From: Al Viro <viro@ZenIV.linux.org.uk>
To: Christian Brauner <christian.brauner@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
hch@infradead.org, tglx@linutronix.de,
kstewart@linuxfoundation.org,
Greg KH <gregkh@linuxfoundation.org>,
pombredanne@nexb.com, Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH 0/6 resend] statfs: handle mount propagation
Date: Thu, 3 May 2018 14:43:17 +0100 [thread overview]
Message-ID: <20180503134317.GA30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAPP7u0VPyWAsL_kkb4JnJHMmK=kM0m4zRjVjst1iHDd6V=t0mQ@mail.gmail.com>
On Thu, May 03, 2018 at 03:04:36PM +0200, Christian Brauner wrote:
> >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.
So what's to stop you from doing exactly that --
mount(NULL, "/", NULL, MS_PRIVATE | MS_REC, NULL)
without bothering with statfs() in the first place? It's not like the
damn thing had been costly - it's O(mounts in your namespace) with not
to high constant, and in any case cheaper than allocating all of them
back when you did clone(2). Confused...
> The above case is what I see most often. A more specific use-case is to
> 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.
>
> For both 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.
Umm... And how would you get the list of mountpoints to feed to statfs()
if not by parsing mountinfo? IDGI...
next prev parent reply other threads:[~2018-05-03 13:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180502154239.14013-1-christian.brauner@ubuntu.com>
2018-05-02 16:09 ` [PATCH 0/6 resend] statfs: handle mount propagation Al Viro
2018-05-03 13:04 ` Christian Brauner
2018-05-03 13:43 ` Al Viro [this message]
2018-05-03 13:57 ` 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=20180503134317.GA30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=christian.brauner@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.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=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).