[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