07 Jan, 2012
1 commit
-
Keep track of vfsmounts belonging to a superblock. List is protected
by vfsmount_lock.Signed-off-by: Miklos Szeredi
Tested-by: Toshiyuki Okajima
Signed-off-by: Al Viro
04 Jan, 2012
21 commits
-
Signed-off-by: Al Viro
-
rationale: that stuff is far tighter bound to fs/namespace.c than to
the guts of procfs proper.Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
make IS_MNT_SLAVE take struct mount * at the same time
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
the second victim...
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
taken out of struct vfsmount into struct mount
Signed-off-by: Al Viro
-
switch __lookup_mnt() to returning struct mount *; callers adjusted.
Signed-off-by: Al Viro
-
Almost all fields of struct vfsmount are used only by core VFS (and
a fairly small part of it, at that). The plan: embed struct vfsmount
into struct mount, making the latter visible only to core parts of VFS.
Then move fields from vfsmount to mount, eventually leaving only
mnt_root/mnt_sb/mnt_flags in struct vfsmount. Filesystem code still
gets pointers to struct vfsmount and remains unchanged; all such
pointers go to struct vfsmount embedded into the instances of struct
mount allocated by fs/namespace.c. When fs/namespace.c et.al. get
a pointer to vfsmount, they turn it into pointer to mount (using
container_of) and work with that.This is the first part of series; struct mount is introduced,
allocation switched to using it.Signed-off-by: Al Viro
-
vfsmounts have ->mnt_parent pointing either to a different vfsmount
or to itself; it's never NULL and termination condition in loops
traversing the tree towards root is mnt == mnt->mnt_parent. At least
one place (see the next patch) is confused about what's going on;
let's add an explicit helper checking it right way and use it in
all places where we need it. Not that there had been too many,
but...Signed-off-by: Al Viro
