Re: [RFC] shared subtrees

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J. Bruce Fields wrote:
> On Mon, Jan 17, 2005 at 02:30:27PM -0500, Mike Waychison wrote:
> 
>>Well, if I understand it correctly:
>>
>>(assuming /foo is vfsmount A)
>>
>>$> mount --make-shared /foo
>>
>>will make A->A
>>
>>$> mount --bind /foo /foo/bar
>>
>>will create a vfsmount B based off A, but because A is in a p-node,
>>A->B, B->A.
>>
>>Then, we attach B to A in the vfsmount tree, but because A->B in the
>>propagation tree, B also gets a vfsmount C added on dentry 'bar'.
>>Recurse ad infinitum.
>>
>>Make sense?
> 
> 
> Yes, but couldn't the whole thing be avoided if we just agreed that the
> propagation wasn't set up till after B was attached to A?

I don't think that solves the problem.  B should receive copies (with
shared semantics if called for) of all mountpoints C1,..,Cn that are
children of A if A->A.  This is regardless of whether or not propagation
occurs before or after the attach.

Allowing this is like allowing directory aliasing in the sense that an
aliased directory that is nested within itself opens us to
badness/headaches 8)

I still think the only way to handle this is to disallow vfsmounts in a
p-node to have (grand)parent-child relationships.  This may have to be
extended to the 'owned by' case as well.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7BvmdQs4kOxk3/MRAkDnAJ0SgZ4KJJXu5gHpCAmgZY199ts3sgCeKFoD
qpQqB+hkExDyuGLOfG8Hnso=
=H4nE
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/