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

viro
2004-08-27T04:30:59Z

On Thu, Aug 26, 2004 at 08:57:40PM -0700, Linus Torvalds wrote:
> 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?

a) set ->d_mount to 1 and set DCACHE_HYBRID at ->lookup() time
b) in lookup_mnt():
if (unlikely(dentry has DCACHE_HYBRID)) {
if (linkely(dentry->d_mount == 1))
goto New;
}
do the normal series of hash lookups
if (likely(dentry doesn't have DCACHE_HYBRID))
return;
if (vfsmount is marked as hybrid && dentry == vfsmount->mnt_dentry)
return;
New:
allocate new vfsmount and mark it as hybrid
attach it on top of our one and go there

Does that qualify as cunning? With that approach we have nothing non-trivial
to do at lookup time and lookup_mnt() will DTRT with minimal fuss.

> 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?

See above. And yes, I'd love to get a separate dentry (and inode, while
we are at it). But I don't see how to do that.

One note: we might split lookup_mnt() in two functions - one for the
middle of lookup, another for final (non-triggering) step.