From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: virtio-fs-list <virtio-fs@redhat.com>,
Max Reitz <mreitz@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Virtio-fs] [PATCH] virtiofsd: Show submounts
Date: Wed, 29 Apr 2020 08:34:24 -0400 [thread overview]
Message-ID: <20200429123424.GA231284@redhat.com> (raw)
In-Reply-To: <CAOssrKcZr4QXV1qLO7wmvdutkPKm59nSquPisEApBCWGx-c-uA@mail.gmail.com>
On Wed, Apr 29, 2020 at 11:26:49AM +0200, Miklos Szeredi wrote:
> On Wed, Apr 29, 2020 at 9:59 AM Miklos Szeredi <mszeredi@redhat.com> wrote:
> >
> > On Tue, Apr 28, 2020 at 9:15 PM Dr. David Alan Gilbert
> > <dgilbert@redhat.com> wrote:
> >
> > > So our current sequence is:
> > >
> > > (new namespace)
> > > 1) if (mount(NULL, "/", NULL, MS_REC | MS_SLAVE, NULL) < 0) {
> > > 2) if (mount("proc", "/proc", "proc",
> > > ....
> > > 3) if (mount(source, source, NULL, MS_BIND | MS_REC, NULL) < 0) {
> > > 4) (chdir newroot, pivot, chdir oldroot)
> > > 5) if (mount("", ".", "", MS_SLAVE | MS_REC, NULL) < 0) {
> > > 6) if (umount2(".", MNT_DETACH) < 0) {
> > >
> > > So are you saying we need a:
> > > if (mount(NULL, "/", NULL, MS_REC | MS_SHARED, NULL) < 0) {
> > >
> > > and can this go straight after (1) ?
> >
> > Or right before (3). Important thing is that that new mount will
> > only receive propagation if the type of the mount at source (before
> > (3) is performed) is shared.
>
> And seems I was wrong. Bind mounting clones the slave property, hence
> no need to set MS_SHARED. I.e. if the source was a slave, the bind
> mount will be a slave to the same master as well; the two slaves won't
> receive propagation between each other, but both will receive
> propagation from the master.
Agreed. I was playing with it yesterday and noticed the same thing. Wanted
to test more before I said anything
Anyway, I did following.
$ mkdir /tmp/a /tmp/a/c /tmp/b
$ mount --bind /tmp/a /tmp/a
$ findmnt -o +PROPAGATION /tmp/a
TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/tmp/a tmpfs[/a] tmpfs rw,nosuid,nodev,seclabel shared
$ cat /proc/self/mountifo | grep "/tmp/a"
613 49 0:45 /a /tmp/a rw,nosuid,nodev shared:30 - tmpfs tmpfs rw,seclabel
# Mountpoint /tmp/a is part of peer group "30"
# Create a new mount namespace with slave propagation
$ unshare -m --propagation slave bash
$ findmnt -o +PROPAGATION /tmp/a
TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/tmp/a tmpfs[/a] tmpfs rw,nosuid,nodev,seclabel private,slave
$ cat /proc/self/mountinfo | grep /tmp/a
666 665 0:45 /a /tmp/a rw,nosuid,nodev master:30 - tmpfs tmpfs rw,seclabel
# /tmp/a in new mount namespace is slave of master "30"
# bind mount /tmp/a to /tmp/b and b should become slave of "30" too.
$ mount --bind /tmp/a /tmp/b
$findmnt -o +PROPAGATION /tmp/b
TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/tmp/b tmpfs[/a] tmpfs rw,nosuid,nodev,seclabel private,slave
$ cat /proc/self/mountinfo | grep /tmp/b
671 665 0:45 /a /tmp/b rw,nosuid,nodev master:30 - tmpfs tmpfs rw,seclabel
# So /tmp/b is slave of "master:30" too. Say if host mounts something
# under /tmp/a (in init namespace), it should propagate to /tmp/a as
# well as /tmp/b in new mount namespace.
# Do following in init mount namespace
$ mount --bind /tmp/a/c /tmp/a/c
# Check in newly created mount namespace.
# findmnt
├─/tmp tmpfs tmpfs rw,nosuid,nodev,seclab
│ ├─/tmp/a tmpfs[/a] tmpfs rw,nosuid,nodev,seclab
│ │ └─/tmp/a/c tmpfs[/a/c] tmpfs rw,nosuid,nodev,seclab
│ ├─/tmp/b tmpfs[/a] tmpfs rw,nosuid,nodev,seclab
│ │ └─/tmp/b/c tmpfs[/a/c] tmpfs rw,nosuid,nodev,seclab
│ └─/tmp/a/c tmpfs[/a/c] tmpfs rw,nosuid,nodev,seclab
Mount of c has propagated into /tmp/b/c as well.
And that's what we want.
Thanks
Vivek
next prev parent reply other threads:[~2020-04-29 12:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 13:35 [PATCH] virtiofsd: Show submounts Max Reitz
2020-04-27 17:59 ` Dr. David Alan Gilbert
2020-04-28 6:06 ` Max Reitz
2020-04-28 9:59 ` Dr. David Alan Gilbert
2020-04-28 10:13 ` Max Reitz
2020-04-28 10:19 ` Dr. David Alan Gilbert
2020-04-28 8:46 ` Daniel P. Berrangé
2020-04-28 14:51 ` Stefan Hajnoczi
2020-04-28 14:58 ` Daniel P. Berrangé
2020-04-28 19:07 ` [Virtio-fs] " Miklos Szeredi
2020-04-28 19:15 ` Dr. David Alan Gilbert
2020-04-29 7:59 ` Miklos Szeredi
2020-04-29 9:26 ` Miklos Szeredi
2020-04-29 12:34 ` Vivek Goyal [this message]
2020-04-29 12:41 ` Vivek Goyal
2020-04-29 8:31 ` Max Reitz
2020-04-29 8:52 ` Miklos Szeredi
2020-04-29 9:31 ` Max Reitz
2020-04-29 14:57 ` Dr. David Alan Gilbert
2020-04-29 15:35 ` Vivek Goyal
2020-04-30 8:06 ` Max Reitz
2020-04-30 8:58 ` Dr. David Alan Gilbert
2020-04-30 9:21 ` Max Reitz
2020-04-30 11:38 ` Max Reitz
2020-04-30 13:56 ` Vivek Goyal
2020-04-30 14:20 ` Dr. David Alan Gilbert
2020-04-30 14:24 ` Vivek Goyal
2020-04-30 14:34 ` Daniel P. Berrangé
2020-04-30 14:41 ` Vivek Goyal
2020-04-30 14:47 ` Daniel P. Berrangé
2020-04-30 15:41 ` Vivek Goyal
2020-05-01 17:53 ` Dr. David Alan Gilbert
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=20200429123424.GA231284@redhat.com \
--to=vgoyal@redhat.com \
--cc=dgilbert@redhat.com \
--cc=mreitz@redhat.com \
--cc=mszeredi@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-fs@redhat.com \
/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).