[CRIU] [PATCH CRIU 0/4] mount: fixes for slave mounts

Tycho Andersen tycho.andersen at canonical.com
Thu Jan 28 03:34:24 PST 2016


On Wed, Jan 27, 2016 at 05:13:54PM +0300, Pavel Emelyanov wrote:
> On 01/20/2016 06:42 PM, Pavel Tikhomirov wrote:
> > Main problem I was trying to solve that migrating Virtuozzo container
> > some slave mounts which at the same time were shared, become shared
> > only. They lost "master:%d" in /proc/self/mountinfo output. It was
> > because we made those mounts private before making them slave.
> > 
> > https://jira.sw.ru/browse/PSBM-42829
> > 
> > Pavel Tikhomirov (4):
> >   mount: get over autodetected mounts in search for widest shared peer
> >   mount: do not make external mounts to be private if not needed
> >   mount: do not mark mount internaly shared if match is master not share
> >   mount: if mount should have master we must not set mount private
> > 
> >  mount.c | 26 ++++++++++++++++++++++----
> >  1 file changed, 22 insertions(+), 4 deletions(-)
> > 
> 
> Andrey, Tycho, what do we do with this set? Do you Ack all patches of
> it, want Pavel to rework/fix or is it up to ... the maintainer :) ?

I guess I don't understand exactly what this set is trying to fix (I
can't resolve jira.sw.ru, so I can't read the original bug report). At
least in the description above, it seems like the right thing to do is
fix the internal_sharing flag so that it's really something like
needs_private_remount, since internal_sharing is sort of half assed
(i.e. it misses external slavery, as this bug report points out).

Basically, don't we want to fix the issue described in this comment

                        /*
                         * In order to support something like internal slavery,
                         * we need to teach can_mount_now and do_mount_one
                         * about slavery relationships in external mounts. This
                         * seems like an uncommon case, so we punt for not.
                         */

?

I don't mind merging these for now, but it seems perhaps we need more careful
thought in this area.

Tycho


More information about the CRIU mailing list