add several pieces to shared subtree documentation

* document locking
* add the missing part of data structure invariants (relationship
between mnt_share and mnt_slave lists in case of a peer group
among slaves).

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This commit is contained in:
Al Viro 2010-01-16 14:10:21 -05:00
parent 796a6b521d
commit 2f99cc6e46
1 changed files with 15 additions and 1 deletions

View File

@ -837,6 +837,9 @@ replicas continue to be exactly same.
individual lists does not affect propagation or the way propagation individual lists does not affect propagation or the way propagation
tree is modified by operations. tree is modified by operations.
All vfsmounts in a peer group have the same ->mnt_master. If it is
non-NULL, they form a contiguous (ordered) segment of slave list.
A example propagation tree looks as shown in the figure below. A example propagation tree looks as shown in the figure below.
[ NOTE: Though it looks like a forest, if we consider all the shared [ NOTE: Though it looks like a forest, if we consider all the shared
mounts as a conceptual entity called 'pnode', it becomes a tree] mounts as a conceptual entity called 'pnode', it becomes a tree]
@ -874,8 +877,19 @@ replicas continue to be exactly same.
NOTE: The propagation tree is orthogonal to the mount tree. NOTE: The propagation tree is orthogonal to the mount tree.
8B Locking:
8B Algorithm: ->mnt_share, ->mnt_slave, ->mnt_slave_list, ->mnt_master are protected
by namespace_sem (exclusive for modifications, shared for reading).
Normally we have ->mnt_flags modifications serialized by vfsmount_lock.
There are two exceptions: do_add_mount() and clone_mnt().
The former modifies a vfsmount that has not been visible in any shared
data structures yet.
The latter holds namespace_sem and the only references to vfsmount
are in lists that can't be traversed without namespace_sem.
8C Algorithm:
The crux of the implementation resides in rbind/move operation. The crux of the implementation resides in rbind/move operation.