Message-ID: <1353724641.2348.56.camel@perseus.themaw.net>
Date:	Sat, 24 Nov 2012 10:37:21 +0800
From:	Ian Kent <raven@...maw.net>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	autofs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, sukadev@...ux.vnet.ibm.com,
	serge.hallyn@...onical.com, ebiederm@...ssion.com
Subject: Re: [PATCH 1/2] autofs4: allow autofs to work outside the initial
 PID namespace

On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
> > Ian Kent <raven@...maw.net> writes:
> > 
> > > On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
> > >> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
> > >> > Patches were tested by the customer.
> > >> > 
> > >> > Ian, Eric, do these patches look OK?
> > >> 
> > >> They look OK to me but I'm still a bit concerned about changing the way
> > >> this behaves, but I also believe this is the way we want it to behave.
> > >
> > > OK, I ran the autofs Connectathon tests that I often use on a kernel
> > > with these patches and they worked fine. So, AFAICS. the patches
> > > shouldn't introduce regressions.
> > 
> > And the reason for that is the patches introduce no behavioral changes
> > at all if the automount daemon was started in the initial namespace.
> 
> Sure but I had to check.
> 
> > 
> > They only change (and fix) semantics of the case when automount is
> > started in a cloned pid namespace.
> > 
> > >
> > >> 
> > >> Give me a little bit more time to run a simple test to ensure we can at
> > >> least do what we could previously, and that's nothing more than
> > >> umounting duplicated mounts (which probably shouldn't be duplicated at
> > >> all) in the container.
> > >
> > > Interestingly the simple container test program I have also worked in
> > > the same way it does on current kernels so again I didn't see a problem
> > > adding the patches.
> > >
> > > But I do have a couple of questions that are a little related.
> > >
> > > Calling clone(2) with flags
> > > CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET
> > > will result in a copy of the existing set of mounts. The autofs mounts
> > > can be umounted if they are not needed.
> > >
> > > But, on Fedora systemd sets "/" as shared at boot which prevents the
> > > umount of these autofs mounts, unless you mark "/" as private in the
> > > clone, after which the mounts can be umounted.
> > >
> > > Does having "/" marked as shared in the root namespace mean that further
> > > mounts in the root namespace will also appear in the clone and that
> > > mounts done in the clone will appear in the root namespace?
> > 
> > Yes.
> > 
> > >
> > > Will mounting all autofs mounts with MS_PRIVATE prevent the autofs
> > > mounts and any mounts under them from appearing in the root namespace?
> > 
> > Changing autofs mounts to MS_PRIVATE will prevent submounts of these
> > from being propagated to/from the root namespace.
> 
> Right, but maybe I don't understand what you mean by the "from" here.
> 
> AFAICS autofs mounts mounted with MS_PRIVATE in the initial namespace do
> propagate to the clone when it's created so I'm assuming subsequent
> mounts would also. If these mounts are busy in some way they can't be
> umounted in the clone unless "/" is marked private before attempting the
> umount.

This may sound stupid but if there something like, say, MS_NOPROPAGATE
then the problem I see would pretty much just go away. No more need to
umount existing mounts and container instances would be isolated. But, I
guess, I'm not considering the possibility of cloned of processes as
well .... if that makes sense, ;)

Ian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists