> > Right. After locking vfsmount_lock, mount_dironfile() should recheck > > if there was a race and bail out. > > Owww... Not pretty, that...
If the cost of ->enter() is low, then it shouln't really be a problem. We can't use ->i_mutex for locking, and introducing a new lock for this doesn't sound right either. > > I don't think the filesystem ought to try _creating_ a vfsmount. I > > imagine, that the fs has already a kernel-internal mounted for this > > kind of stuff, and it just supplies a dentry from that. The vfsmount > > isn't actually important, but it should be readily available, and it's > > easier to clone from a vfsmount/dentry pair. > > I don't get it. What's the point of that exercise, then? When do you > create that kernel-internal mount? When the real superblock is created. It could even be the _same_ super block as the real one. There'd be just the problem of anchoring the dir-on-file dentries somewhere... Or with fuse the dir-on-file mount can just come from any mounted filesystem, again possibly the same one as the parent. I do actually test with this. The userspace filesystem supplies a file descriptor, from which the struct path is extracted and returned from ->enter(). Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
