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>,
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
WARNING: multiple messages have this Message-ID (diff)
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:34 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 13:35 [Virtio-fs] [PATCH] virtiofsd: Show submounts Max Reitz
2020-04-24 13:35 ` Max Reitz
2020-04-27 17:59 ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-27 17:59 ` Dr. David Alan Gilbert
2020-04-28 6:06 ` [Virtio-fs] " Max Reitz
2020-04-28 6:06 ` Max Reitz
2020-04-28 9:59 ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-28 9:59 ` Dr. David Alan Gilbert
2020-04-28 10:13 ` [Virtio-fs] " Max Reitz
2020-04-28 10:13 ` Max Reitz
2020-04-28 10:19 ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-28 10:19 ` Dr. David Alan Gilbert
2020-04-28 8:46 ` [Virtio-fs] " Daniel P. Berrangé
2020-04-28 8:46 ` Daniel P. Berrangé
2020-04-28 14:51 ` [Virtio-fs] " Stefan Hajnoczi
2020-04-28 14:51 ` Stefan Hajnoczi
2020-04-28 14:58 ` [Virtio-fs] " Daniel P. Berrangé
2020-04-28 14:58 ` Daniel P. Berrangé
2020-04-28 19:07 ` [Virtio-fs] " Miklos Szeredi
2020-04-28 19:07 ` Miklos Szeredi
2020-04-28 19:15 ` Dr. David Alan Gilbert
2020-04-28 19:15 ` Dr. David Alan Gilbert
2020-04-29 7:59 ` Miklos Szeredi
2020-04-29 7:59 ` Miklos Szeredi
2020-04-29 9:26 ` Miklos Szeredi
2020-04-29 9:26 ` Miklos Szeredi
2020-04-29 12:34 ` Vivek Goyal [this message]
2020-04-29 12:34 ` Vivek Goyal
2020-04-29 12:41 ` Vivek Goyal
2020-04-29 12:41 ` Vivek Goyal
2020-04-29 8:31 ` Max Reitz
2020-04-29 8:31 ` Max Reitz
2020-04-29 8:52 ` Miklos Szeredi
2020-04-29 8:52 ` Miklos Szeredi
2020-04-29 9:31 ` Max Reitz
2020-04-29 9:31 ` Max Reitz
2020-04-29 14:57 ` Dr. David Alan Gilbert
2020-04-29 14:57 ` Dr. David Alan Gilbert
2020-04-29 15:35 ` [Virtio-fs] " Vivek Goyal
2020-04-29 15:35 ` Vivek Goyal
2020-04-30 8:06 ` [Virtio-fs] " Max Reitz
2020-04-30 8:06 ` Max Reitz
2020-04-30 8:58 ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-30 8:58 ` Dr. David Alan Gilbert
2020-04-30 9:21 ` [Virtio-fs] " Max Reitz
2020-04-30 9:21 ` Max Reitz
2020-04-30 11:38 ` [Virtio-fs] " Max Reitz
2020-04-30 11:38 ` Max Reitz
2020-04-30 13:56 ` [Virtio-fs] " Vivek Goyal
2020-04-30 13:56 ` Vivek Goyal
2020-04-30 14:20 ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-30 14:20 ` Dr. David Alan Gilbert
2020-04-30 14:24 ` [Virtio-fs] " Vivek Goyal
2020-04-30 14:24 ` Vivek Goyal
2020-04-30 14:34 ` [Virtio-fs] " Daniel P. Berrangé
2020-04-30 14:34 ` Daniel P. Berrangé
2020-04-30 14:41 ` [Virtio-fs] " Vivek Goyal
2020-04-30 14:41 ` Vivek Goyal
2020-04-30 14:47 ` [Virtio-fs] " Daniel P. Berrangé
2020-04-30 14:47 ` Daniel P. Berrangé
2020-04-30 15:41 ` [Virtio-fs] " Vivek Goyal
2020-04-30 15:41 ` Vivek Goyal
2020-05-01 17:53 ` [Virtio-fs] " Dr. David Alan Gilbert
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=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 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.