On Thu, 26 Aug 2004 [EMAIL PROTECTED] wrote:
> >
> > It should be reasonably easy to create new ones on-the-fly, since we'd
> > have all the information (the parent vfsmount comes stated, and the
> > vfsmount we create would point to the same things that the "base" one
> > would).
>
> Erm... What do we do upon unlink()? I'm killing a file, fs it's in is
> mounted in a dozen of places (no namespaces, just chroot jails, whatever).
> We need to find all vfsmounts to be killed by that.
But that should be trivial: that's what the per-inode vfsmount list was
(your first question in the last email).
> And BTW that's an argument against anchoring that list in inode - unlink()
> on foo should not screw bar/... even if bar and foo are links to the same
> file. So we'll need to check for dentry match anyway.
And again - I talked about this in the previous email. Even if you anchor
the list in "struct inode", or you do it with a totally external
hash-list, you'll always have the "vfsmount->mnt_mountpoint" pointer to
point to the dentry. So you can just iterate over the list, and
cherry-pick the ones that point to the dentry you are removing.
>
> > > 3) what do we do on umount(2)? We can get a bunch of vfsmounts hanging off
> > > it. MNT_DETACH will have no problems, but normal umount() is a different
> > > story. Note that it's not just hybrid-related problem - implementing the
> > > mount traps will cause the same kind of trouble,
> >
> > Don't allow umount. It's not something the user can unmount - the mount is
> > "implied" in the file.
>
> See below.
>
> > > 4) OK, we have those hybrids and want to create vfsmounts when crossing a
> > > mountpoint. When do they go away, anyway? When we don't reference them
> > > anymore? Right now "attached to mount tree" == "+1 to refcount" and detaching
> > > happens explicitly - outside of the "dropping the final reference" path.
> > > Might become a locking issue.
> >
> > Ahh. Umm.. Yes. I think this might be the real problem. Unless I seriously
> > clossed something over when I blathered about the "create the vfsmount on
> > the fly" thing above ;)
>
> > > 5) Creation of these vfsmounts: fs should somehow tell us whether it wants
> > > one or not (at the very least, we should stop *somewhere*). Can we use
> > > the same dentry/inode? I'm not sure and I really doubt that we'd like that.
> >
> > Why not? When doing the ->lookup() operation, the filesystem would create
> > the vfsmount and bind it to the current vfsmount. That guarantees that it
> > has a vfsmount, and will mean that it will show up positive with the
> > "d_mountpoint()" query, which in turn will cause us to do the
> > "lookup_mnt()".
>
> Several paragraphs below you are saying that you don't like fs messing with
> vfsmounts. Use of ->lookup() would mean that we should not only create
> and attach vfsmounts from within fs code, but would actually have to make
> ->lookup() return vfsmount+dentry, AFAICS.
No, lookup would just return the dentry, but the dentry would already be
filled in with the mount-point information.
And you can do that with a simple vfs helper function, ie the filesystem
itself would just need to do
pseudo_mount(dentry, inode);
thing - which just fills in dentry->d_mountpoint with a new vfsmount
thing. It would allocate a new root dentry (for the pseudo-mount) and a
new vfsmount, and make dentry->d_mountpoint point to it.
IOW, the filesystem itself would never mess around with d_mountpoint
itself.
> Err... What about dir-on-dir-that-is-on-file? I.e. mount on foo/. when foo
> is a file?
Hmm.. We might as well allow it, I suspect. It's not like it should hurt.
We'd end up following the mount-chain twice, but we already have that
issue with multi-mount cases..
Linus
