On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote: > > 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? > > 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? > 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(). 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... > 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. - 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
