Re: [some sanity for a change] possible design issues for hybrids

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 27 Aug 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> > 
> > I agree. I frankly have no idea how to do it. I think we need to keep them
> > around for as long as the dentry lifetime, I suspect. That would likely
> > imply that the vfsmount can't increase the dentry refcount - and we'd have
> > some special code in dentry_iput() or something to get rid of them.
> 
> My plan is to drop them as soon as their refcount goes to zero.  In other
> words, make the final mntput() do removal from tree for such vfsmounts.

Can't do that. At least not if you do my plan. 

Even with a zero refcount, the dentry is still valid, and won't see a new 
"->lookup()". And since in my scheme the vfsmount is populated only at 
lookup (and copied later), you can't drop _all_ the vfsmount's. You'd have 
to at least leave one of them, in order to know how to re-create the 
others.

Or do you have a cunning plan?

> > > can get very ugly, since fs could be mounted in a lot of places and/or
> > > in a lot of namespaces.
> > 
> > It _might_ be acceptable to just do the normal shrink_dentry thing, and 
> > then return EBUSY if somebody is still there. 
> 
> We need it for graceful invalidation in case of NFS and friends, though.
> I think it might be doable; if it isn't, we'll see what else can be done,
> but it's worth investigating.

Hey, succeeding and leaving it pending is obviously the user-friendly
thing to do, so I won't argue against it. It's more of a "if it's too hard
to do right, EBUSY is probably an acceptable fallback".

> > Hmm.. Wouldn't the "directory" dentry always be the fake-mountpoint root 
> > one? So we'd always have two dentries, although they are tied together 
> > pretty tightly..
> 
> No.  We don't want to allocate dentries outside of fs code - if nothing
> else, they may need to have proper ->d_op set, etc.  So the only way I
> see here is to have lookup_mnt() set the dentry it got to ->mnt_root of
> new vfsmount.  Anything else opens such a can of worms that I don't want
> to think of audit involved.

Hmm. If you use the same dentry for mnt_root as for mnt_mountpoint, how do 
you avoid the infinite loop in follow_mount? Another magic special case?

			Linus