[lkml]   [2005]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] shared subtrees
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.
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.089 / U:11.384 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site