Merge branch 'for-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

and experimenting easier, the kernel parameter cgroup_no_v1= allows

disabling controllers in v1 and make them always available in v2.

cgroup v2 currently supports the following mount options.

  nsdelegate

	Consider cgroup namespaces as delegation boundaries.  This

	option is system wide and can only be set on mount or modified

	through remount from the init namespace.  The mount option is

	ignored on non-init namespace mounts.  Please refer to the

	Delegation section for details.

2-2. Organizing Processes

2-5-1. Model of Delegation

A cgroup can be delegated to a less privileged user by granting write

access of the directory and its "cgroup.procs" file to the user.  Note

that resource control interface files in a given directory control the

distribution of the parent's resources and thus must not be delegated

along with the directory.

Once delegated, the user can build sub-hierarchy under the directory,

organize processes as it sees fit and further distribute the resources

it received from the parent.  The limits and other settings of all

resource controllers are hierarchical and regardless of what happens

in the delegated sub-hierarchy, nothing can escape the resource

restrictions imposed by the parent.

A cgroup can be delegated in two ways.  First, to a less privileged

user by granting write access of the directory and its "cgroup.procs"

and "cgroup.subtree_control" files to the user.  Second, if the

"nsdelegate" mount option is set, automatically to a cgroup namespace

on namespace creation.

Because the resource control interface files in a given directory

control the distribution of the parent's resources, the delegatee

shouldn't be allowed to write to them.  For the first method, this is

achieved by not granting access to these files.  For the second, the

kernel rejects writes to all files other than "cgroup.procs" and

"cgroup.subtree_control" on a namespace root from inside the

namespace.

The end results are equivalent for both delegation types.  Once

delegated, the user can build sub-hierarchy under the directory,

organize processes inside it as it sees fit and further distribute the

resources it received from the parent.  The limits and other settings

of all resource controllers are hierarchical and regardless of what

happens in the delegated sub-hierarchy, nothing can escape the

resource restrictions imposed by the parent.

Currently, cgroup doesn't impose any restrictions on the number of

cgroups in or nesting depth of a delegated sub-hierarchy; however,

2-5-2. Delegation Containment

A delegated sub-hierarchy is contained in the sense that processes

can't be moved into or out of the sub-hierarchy by the delegatee.  For

a process with a non-root euid to migrate a target process into a

cgroup by writing its PID to the "cgroup.procs" file, the following

conditions must be met.

can't be moved into or out of the sub-hierarchy by the delegatee.

For delegations to a less privileged user, this is achieved by

requiring the following conditions for a process with a non-root euid

to migrate a target process into a cgroup by writing its PID to the

"cgroup.procs" file.

- The writer must have write access to the "cgroup.procs" file.

not have write access to its "cgroup.procs" files and thus the write

will be denied with -EACCES.

For delegations to namespaces, containment is achieved by requiring

that both the source and destination cgroups are reachable from the

namespace of the process which is attempting the migration.  If either

is not reachable, the migration is rejected with -ENOENT.

2-6. Guidelines

- Multiple hierarchies including named ones are not supported.

- All mount options and remounting are not supported.

- All v1 mount options are not supported.

- The "tasks" file is removed and "cgroup.procs" is not sorted.

enum {

	CGRP_ROOT_NOPREFIX	= (1 << 1), /* mounted subsystems have no named prefix */

	CGRP_ROOT_XATTR		= (1 << 2), /* supports extended attributes */

	/*

	 * Consider namespaces as delegation boundaries.  If this flag is

	 * set, controller specific interface files in a namespace root

	 * aren't writeable from inside the namespace.

	 */

	CGRP_ROOT_NS_DELEGATE	= (1 << 3),

};

/* cftype->flags */

enum {

	CFTYPE_ONLY_ON_ROOT	= (1 << 0),	/* only create on root cgrp */

	CFTYPE_NOT_ON_ROOT	= (1 << 1),	/* don't create on root cgrp */

	CFTYPE_NS_DELEGATABLE	= (1 << 2),	/* writeable beyond delegation boundaries */

	CFTYPE_NO_PREFIX	= (1 << 3),	/* (DON'T USE FOR NEW FILES) no subsys prefix */

	CFTYPE_WORLD_WRITABLE	= (1 << 4),	/* (DON'T USE FOR NEW FILES) S_IWUGO */

	/* the default cgroup associated with this css_set */

	struct cgroup *dfl_cgrp;

	/* internal task count, protected by css_set_lock */

	int nr_tasks;

	/*

	 * Lists running through all tasks using this cgroup group.

	 * mg_tasks lists tasks which belong to this cset but are in the

	  inet sockets.

config CGROUP_DEBUG

	bool "Example controller"

	bool "Debug controller"

	default n

	depends on DEBUG_KERNEL

	help

	  This option enables a simple controller that exports

	  debugging information about the cgroups framework.

	  debugging information about the cgroups framework. This

	  controller is for control cgroup debugging only. Its

	  interfaces are not stable.

	  Say N.

obj-$(CONFIG_CGROUP_PIDS) += pids.o

obj-$(CONFIG_CGROUP_RDMA) += rdma.o

obj-$(CONFIG_CPUSETS) += cpuset.o

obj-$(CONFIG_CGROUP_DEBUG) += debug.o

int cgroup_show_path(struct seq_file *sf, struct kernfs_node *kf_node,

		     struct kernfs_root *kf_root);

int cgroup_task_count(const struct cgroup *cgrp);

/*

 * namespace.c

 */