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

[Ram Pai <linuxram@us.ibm.com>]

On Tue, 2005-11-08 at 07:55, Miklos Szeredi wrote:
> > No. As explained in the same earlier threads; without this change the
> > behavior of shared-subtrees leads to inconsistency and confusion in some
> > scenarios.
> > 
> > Under the premise that no application should depend on this behavior
> > (most-recent-mount-visible v/s top-most-mount-visible),
> 
> The strongest argument against was that
> 
>   mount foo .; umount .
> 
> would no longer be a no-op.

It is a no-op even now.  Try it.

What you meant was something like this is no-op now?

P1: cd /tmp1
P2: mount --bind /var /tmp1
P1: mount --bind /bin .
P1: umount .
 
Yes this will not be a noop with my changes. However this behavior is
not documented to be a no-op anywhere. right? 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?

My changes just changes one behavior and that is:
If multiple mounts are mounted on the same <mount,dentry> combination
the later mounts are obscured by the preceeding mounts. Earlier it was
opposite behavior.

My biggest complaint about the earlier behavior was that the later
mounts obscured not only the earlier mounts on the <mount,dentry> tuple,
but also obscured all the mounts that got stacked on top of the
earlier <mount,dentry>.  It seemed totally unnatural, and confusing
with shared-subtree.  


> > Al Viro permitted this change. And this is certainly the right
> > behavior.
> 
> Which is a contradiction in term, since you are saying that
> applications _do_ depend on it.

no. I said application _should_not_ depend on it, because it is a
undefined semantics.

Sorry I was out yesterday and could reply earlier.
RP

> 
> Miklos