LU-4476 kernel: support process namespace containers

LU-4476 kernel: support process namespace containers

PID namespace was introduce to linux to allow the
migration of containers between hosts. This way running
processes could be migrated to a new machine without
interruption due to pid collisions. User namespace creates
a new enviroment for a exist process where in this new
namespace it will have different uid/gid. Outside that
namespace the default uid/gid. For example a unprivileged
application can create user namespace for itself which has
root privilages. Those privilages don't exist outside of
the created namespace. Both of these changed the traditonal
one to one kernel mapping for pids/gids has changed. Since
userland can now have multiple PID namespaces this means that
each namespace in userland could have the same pid assigned.
This is possible since each namespace will be isolated from
each other. In the case of User namespace the application can
report to the kernel its namespace uid/gid instead of its real
uid/gid. Since the same running kernel is used between all
namespaces on a host the pid/gid data that is pushed into a
kernel context will have to map to a unique pid/gid in kernel
space to avoid collisions. This very similar to Lustre using
FIDs to avoid inode collisions. An example of where the mapping
needs to take place are when pid/gid data is pushed via a ioctl.
Also the internal structures of the kernel store uid/gid in the
kernel internal format. Lastly even with lustre userland uid/gid
namespace being consistant to applications the transmitted
uid/gid will be represented in the kernel differently from
server to server. Lustre wire protocols transmitting uid/gid
must handle these cases.

Change-Id: I207492b9a8a762e43ac2dd8fd1fb1b7397505304
Signed-off-by: James Simmons <uja.ornl@gmail.com>
Reviewed-on: http://review.whamcloud.com/8817
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Yang Sheng <yang.sheng@intel.com>
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>