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@xxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
