> 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.
> 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?
> 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.
Miklos
-
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]
