> > > Eh...  Arbitrary limitations are fun, aren't they?
quoted text
> > 
> > But these mounts _are_ special.  There is really no point in moving or
> > pivoting them.
> 
> pivoting - probably true, moving... why not?

I don't see any use for that.  But indeed, it should not be too hard
to do.

quoted text
> > > What about MNT_SLAVE stuff being set up prior to that lookup?
> > 
> > These mounts are not propagated.  Or at least I hope so.  Propagation
> > stuff is a bit too complicated for my poor little brain.
> 
> Er...  These mounts might not be propagated, but what about a bind
> over another instance of such file in master tree?

So your question is, which mount takes priority on the lookup?  It
probably should be the propagated real mount, rather than the
dir-on-file one, shouldn't it?

quoted text
> > I think they should be the same superblock, same dentry.  What would
> > be the advantage of doing otherwise?
> 
> Then you are going to have interesting time with locking in final mntput().

Final mntput of what?

quoted text
> BTW, what about having several links to the same file?  You have i_mutex
> on the inode, so serialization of those is not a problem, but...

Sorry, I lost it...

quoted text
> > I think doing this recursively should be allowed.  "Releasing last ref
> > cleans up the mess" should work in that case.
> 
> Releasing the last reference will lead to cascade of umounts in that
> case...  IOW, need to be careful with locking.

I think it's done right: detach_mnt() with namespace_sem and
vfsmount_lock, then release locks, and path_release(&old_nd).

If the recursion is extremely deep we could have stack overflow
problems though, aargh...

Miklos