On Mon, 23 May 2005, Miklos Szeredi wrote:
I've been investigating a bug report about bind mounting an autofs
controlled mount point. It is indeed disastrous for autofs. It would be
simple enough it to check and fail silently but that won't give sensible
behavior.
What should the semantics be for these type of mount requests against
autofs?
First, a move mount doesn't make sense as it places the autofs
filesystem in a location that is not specified in the autofs map to which
it belongs. It looks like the user space daemon would loose contact with
the newly mounted filesystem and so it would become useless and probably
not umountable, not to mention how the daemon would handle it. I believe
that this shouldn't be allowed. What do people think? If we don't treat
these as invalid then how should they behave?
Move is very similar to rbind + umount. So if you find sane semantics
for the rbind case, that should do for move as well.
Perhaps not in this case.
If I read it correctly rbind is a copy of the mount tree. It leaves behind
the original. A move operation appears to copy the tree and then
basically umounts the source tree.
For autofs the originating mount point is owned and controled by the
userspace daemon and the corresponding automount map specifies what may be
mounted. We can't just umount it without cooperation from the daemon.
Bind mount requests are another question.
In the case of a bind mount we can find ourselves with a dentry in the
bound filesystem that is marked as mounted but can't be followed
because the parent vfsmount is in the source filesystem.
I don't understand this. A bind will just copy a vfsmount and add the
copy to some other place in the mount tree. It should not matter if
the original mount was automounted or not. What am I missing?
And assigns the same super block and root dentry.
The problem is that when an autofs dentry is walked on it sends a message
to the userspace daemon. The daemon performs the corresponding mount, in
the source filesystem, causing a mount to appear in the destination
filesystem as well, but without the correct vfsmount linkages.
Should the automount functionality go along with the bind mount
filesystem?
No. With bind you copy the mount to another place. Now it has
nothing to do with the automouter, it becomes a perfectly ordinary
mount.
An autofs4 filesystem is intimately tied to some userspace program. For me
it's the automount daemon and the automount map defining the mountpounts
it knows about.
This is the source of the difficulty in defining the way it should behave.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]