Re: [PATCH 12/18] shared mount handling: bind and rbind

[Al Viro <viro@ftp.linux.org.uk>]

On Wed, Nov 09, 2005 at 10:59:47AM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 9 Nov 2005, Ram Pai wrote:
> >
> > And 'umount .' really doen't make sense. What does it mean? umount the 
> > current mount? or umount of the mount that is mounted on this dentry?
> 
> "umount <directory>" _absolutely_ makes sense, whether "directory" is "." 
> or something else. People do it all the time.

With current (and all previous, actually) tree umount . is usually -EBUSY.

The case Mikulas is talking about is much uglier - it's "mount on top
of current directory, then umount .".  _That_ (i.e. when . is overmounted)
happens to work.  And semantics is really, really not well-defined.

Situation with overmounts is nasty - it's *not* just a chain, unfortunately.
I certainly intended it to be such.  However, we can get a *tree* of
overmounts due to side-effects I've missed back then.

We really need it sanitized (and that's what I'm doing right now), but
yes, it *will* cause user-visible changes.  Incidentally, one of those
will be that umount . will work...

The trouble begins since we allow to attach vfsmounts to the *middle* of
overmount chain.  I.e.

mount foo /tmp
cd /tmp
mount bar .
mount baz .

will end up with *two* vfsmounts having root of foo as mountpoint and having
the same mnt_parent.  Which one is seen depends on phase of moon - the only
answer is "whichever is first in mnt_hash chain".  Which is certainly not a
sane answer.  We need explicit rules dealing with effect of overmounts;
anything that seriously relies on details of current behaviour in that sort
of corner cases is very definitely broken.

And "we allow" above should be read as "Al had not thought about that mess
back in 2001" ;-/  Current behaviour in that sort setups is an accident -
as soon as it gets to such forked chains of overmounts sanity exits stage
left.  To be fixed...