summaryrefslogtreecommitdiff
path: root/Documentation/admin-guide/cgroup-v2.rst
diff options
context:
space:
mode:
authorJohn Sperbeck <jsperbeck@google.com>2023-05-21 22:29:53 +0300
committerTejun Heo <tj@kernel.org>2023-05-23 02:59:37 +0300
commit2bd110339288c18823dcace602b63b0d8627e520 (patch)
treeedbebd30f566d2b054e1448372f6b9702919336f /Documentation/admin-guide/cgroup-v2.rst
parentab1de7ead871ebe6d12a774c3c25de0388cde082 (diff)
downloadlinux-2bd110339288c18823dcace602b63b0d8627e520.tar.xz
cgroup: always put cset in cgroup_css_set_put_fork
A successful call to cgroup_css_set_fork() will always have taken a ref on kargs->cset (regardless of CLONE_INTO_CGROUP), so always do a corresponding put in cgroup_css_set_put_fork(). Without this, a cset and its contained css structures will be leaked for some fork failures. The following script reproduces the leak for a fork failure due to exceeding pids.max in the pids controller. A similar thing can happen if we jump to the bad_fork_cancel_cgroup label in copy_process(). [ -z "$1" ] && echo "Usage $0 pids-root" && exit 1 PID_ROOT=$1 CGROUP=$PID_ROOT/foo [ -e $CGROUP ] && rmdir -f $CGROUP mkdir $CGROUP echo 5 > $CGROUP/pids.max echo $$ > $CGROUP/cgroup.procs fork_bomb() { set -e for i in $(seq 10); do /bin/sleep 3600 & done } (fork_bomb) & wait echo $$ > $PID_ROOT/cgroup.procs kill $(cat $CGROUP/cgroup.procs) rmdir $CGROUP Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: John Sperbeck <jsperbeck@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'Documentation/admin-guide/cgroup-v2.rst')
0 files changed, 0 insertions, 0 deletions