docs: namespace: move it to the admin-guide

As stated at the documentation, this is meant to be for
users to better understand namespaces.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

3 files changed, 0 insertions, 72 deletions

diff --git a/Documentation/namespaces/compatibility-list.rst b/Documentation/namespaces/compatibility-list.rst
deleted file mode 100644
index 318800b2a943..000000000000
--- a/Documentation/namespaces/compatibility-list.rst
+++ /dev/null
@@ -1,43 +0,0 @@
-=============================
-Namespaces compatibility list
-=============================
-
-This document contains the information about the problems user
-may have when creating tasks living in different namespaces.
-
-Here's the summary. This matrix shows the known problems, that
-occur when tasks share some namespace (the columns) while living
-in different other namespaces (the rows):
-
-====	===	===	===	===	====	===
--	UTS	IPC	VFS	PID	User	Net
-====	===	===	===	===	====	===
-UTS	 X
-IPC		 X	 1
-VFS			 X
-PID		 1	 1	 X
-User		 2	 2		 X
-Net						 X
-====	===	===	===	===	====	===
-
-1. Both the IPC and the PID namespaces provide IDs to address
-   object inside the kernel. E.g. semaphore with IPCID or
-   process group with pid.
-
-   In both cases, tasks shouldn't try exposing this ID to some
-   other task living in a different namespace via a shared filesystem
-   or IPC shmem/message. The fact is that this ID is only valid
-   within the namespace it was obtained in and may refer to some
-   other object in another namespace.
-
-2. Intentionally, two equal user IDs in different user namespaces
-   should not be equal from the VFS point of view. In other
-   words, user 10 in one user namespace shouldn't have the same
-   access permissions to files, belonging to user 10 in another
-   namespace.
-
-   The same is true for the IPC namespaces being shared - two users
-   from different user namespaces should not access the same IPC objects
-   even having equal UIDs.
-
-   But currently this is not so.
diff --git a/Documentation/namespaces/index.rst b/Documentation/namespaces/index.rst
deleted file mode 100644
index bf40625dd11a..000000000000
--- a/Documentation/namespaces/index.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-:orphan:
-
-==========
-Namespaces
-==========
-
-.. toctree::
-   :maxdepth: 1
-
-   compatibility-list
-   resource-control
diff --git a/Documentation/namespaces/resource-control.rst b/Documentation/namespaces/resource-control.rst
deleted file mode 100644
index 369556e00f0c..000000000000
--- a/Documentation/namespaces/resource-control.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-===========================
-Namespaces research control
-===========================
-
-There are a lot of kinds of objects in the kernel that don't have
-individual limits or that have limits that are ineffective when a set
-of processes is allowed to switch user ids.  With user namespaces
-enabled in a kernel for people who don't trust their users or their
-users programs to play nice this problems becomes more acute.
-
-Therefore it is recommended that memory control groups be enabled in
-kernels that enable user namespaces, and it is further recommended
-that userspace configure memory control groups to limit how much
-memory user's they don't trust to play nice can use.
-
-Memory control groups can be configured by installing the libcgroup
-package present on most distros editing /etc/cgrules.conf,
-/etc/cgconfig.conf and setting up libpam-cgroup.