don't rely on proc_mounts->m being the first field; container_of()
is there for purpose. No need to bother with ->private, while
we are at it - the same container_of will do nicely.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 6ce6e24e72233073c8ead9419fc5040d44803dae)
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
it's enough to set ->mnt_ns of internal vfsmounts to something
distinct from all struct mnt_namespace out there; then we can
just use the check for ->mnt_ns != NULL in the fast path of
mntput_no_expire()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit f7a99c5b7c8bd3d3f533c8b38274e33f3da9096e)
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I6745946142d2dc69956bb3bb0ed40c5e9c6f3815
Assign a unique proc inode to each namespace, and use that
inode number to ensure we only allocate at most one proc
inode for every namespace in proc.
A single proc inode per namespace allows userspace to test
to see if two processes are in the same namespace.
This has been a long requested feature and only blocked because
a naive implementation would put the id in a global space and
would ultimately require having a namespace for the names of
namespaces, making migration and certain virtualization tricks
impossible.
We still don't have per superblock inode numbers for proc, which
appears necessary for application unaware checkpoint/restart and
migrations (if the application is using namespace file descriptors)
but that is now allowd by the design if it becomes important.
I have preallocated the ipc and uts initial proc inode numbers so
their structures can be statically initialized.
Change-Id: I01d42c2f051fd74b1474d9d8378ccc78174cf3cf
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Git-commit: f80cd4676998eb352d1a8b9df0f3663537a9ce93
Git-repo: https://android.googlesource.com/kernel/common/
[schikk@codeaurora.org: Resolved merge conflicts ]
CRs-Fixed: 901628
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
This will allow for support for unprivileged mounts in a new user namespace.
Change-Id: I861716cf94da385c1805edcc9b43209a9d491b69
Acked-by: "Serge E. Hallyn" <serge@hallyn.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Git-commit: ef2fbdef5dea4621c5a889a46e12526511c8610b
Git-repo: https://android.googlesource.com/kernel/common/
[schikk@codeaurora.org: Resolved merge conflicts ]
CRs-Fixed: 901628
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
setns support for the mount namespace is a little tricky as an
arbitrary decision must be made about what to set fs->root and
fs->pwd to, as there is no expectation of a relationship between
the two mount namespaces. Therefore I arbitrarily find the root
mount point, and follow every mount on top of it to find the top
of the mount stack. Then I set fs->root and fs->pwd to that
location. The topmost root of the mount stack seems like a
reasonable place to be.
Bind mount support for the mount namespace inodes has the
possibility of creating circular dependencies between mount
namespaces. Circular dependencies can result in loops that
prevent mount namespaces from every being freed. I avoid
creating those circular dependencies by adding a sequence number
to the mount namespace and require all bind mounts be of a
younger mount namespace into an older mount namespace.
Add a helper function proc_ns_inode so it is possible to
detect when we are attempting to bind mound a namespace inode.
Change-Id: Ie4eaf4274c58296b5c0e36161076237f60bd6c7c
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Git-commit: 81f4b10adf0802091199ba322ccf5c8a7eee2222
Git-repo: https://android.googlesource.com/kernel/common/
CRs-Fixed: 901628
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
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 <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
Kevin F. Haggerty
Al Viro
Eric W. Biederman
Miklos Szeredi