> > > Eh... Arbitrary limitations are fun, aren't they? > > > > 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. > > > 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? > > 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? > 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... > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
