[lxc-devel] [PATCH] Support MS_SHARED /

Michael H. Warfield mhw at WittsEnd.com
Thu Dec 20 17:10:55 UTC 2012


Hey Serge,

I saw your patch and your comment about being out till the 2nd.  I'm
also out until the 27th myself and away from my clusters.

On Thu, 2012-12-20 at 09:03 -0600, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at ubuntu.com):
> > On 12/20/2012 06:58 AM, Serge Hallyn wrote:
> ...
> > /proc/mounts in the container will also end up being polluted by all the
> > mount points from the host, this in itself doesn't cause any big
> > problem, though the container will try (and fail) to unmount all of those.
> > Is there anything we can do to improve that situation or is that a side
> > effect of MS_SHARED that we can't workaround on our end?

> I think it's actually a side effect of pivot-root after chroot.  You
> have /orig_root/foo/chroot_root/path/new_pivot/put_old.  Then you
> chroot to /orig_root/foo/chroot_root.  When you then pivot to
> /path/new_pivot, what ends up in put_old is /orig_root/foo/chroot_root.
> I'm actually not sure you can trim the mounts which were under
> /orig_root.  We could figure out ones they are by following the chain 
> of mount ids in /proc/self/mountinfo, but we can't reach them to umount
> them.

> It's much like how when you boot a livecd, you see things like
> the rootfs on / as well as /cow on /.  You can't reach the rootfs
> which is parent of the /cow on / any more, but it's in the mounts
> table.

> Now I tested, and with a simple setup we can use a much simpler
> patch which just does mount("", "/", NULL, MS_SLAVE|MS_REC, 0);
> for the whole of chroot_into_slave() (and skips the new umount2()
> in start.c).  The container then starts, and its mounts table
> is clean.

> Where that won't work is in a livecd or any fancy raid setup,
> where your process's / has a parent which is MS_SHARED.

> Michael, can you show me your /proc/self/mountinfo in a f18
> box?

I'll look into this as soon as I'm back at the battle bridge on the 27th
and can check it out.

Once again you've gotten in just ahead of me.  I was thinking about
asking where we stood on this one.  This was next on my priority list to
ask about and here you are.  :-)=)

> > I didn't spend much time reviewing the code itself, but it applied to my
> > local staging tree and built fine, so that's good enough for me :)

> Thanks -  TBH the extra mounts are no more wrong than they are in
> a livecd, so I don't think it's a big problem.  One we can address
> in January.

Concur

> -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20121220/9333f8e2/attachment.pgp>


More information about the lxc-devel mailing list