On Wed, 2016-03-09 at 18:44 +0100, Donald Buczek wrote: > Hi, Kent, > > in 2014 we analyzed and discussed a problem which in my view boiled > down > to "autofs refuses to mount on a path (dentry) which already is > mounted > in another namespace." This is because it uses d_mountpoint ( = > DCACHE_MOUNTED) to decide whether a mount should be attempted or not. > At > that point I selfishly changed our setting to avoid use of mount > namespaces and left you alone with the problem. > > But now we need mount namespaces ourselves using kernel 4.4.2 and the > old problem reoccurred > > So my questions: > > * am I right, that this problem is still unresolved? > * is this considered a bug? I originally made a couple of patches to make autofs namespace aware for this case but I'm still holding on to them because, as I did them, I realized there's quite a bit more going on with this. For example, suppose autofs is namespace aware, the autofs file system has been cloned as part of the namespace creation, the filesystem in the new namespace is propagation private and the automount daemon is running in the root namespace. In this case there's no limit on the number of times the namespace can attempt to trigger a mount which is possibly open to be used as a denial of service attack. So the current ELOOP behaviour is probably needed in this case. Another example, assume the automount daemon is running in the root namespace, there are multiple containers where an indirect mount map has been passed as a volume and the container implementation sets it's mounts as propagation slave. In this case the mounts are mounted in the root namespace and propagated to the containers. And similarly, if there's a bad mount the containers are capped on the number of mount attempts by the current ELOOP behaviour. But ELOOP probably isn't the error return the containers should be getting either and allowing unabated callbacks is probably not good either. There are more cases, some of which I haven't properly investigated. So I ended up holding onto the patches. What exactly is your usage need? Ian -- To unsubscribe from this list: send the line "unsubscribe autofs" in
