All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
	Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [PATCH 2/3] cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns
Date: Fri, 15 Jul 2016 00:16:34 -0500	[thread overview]
Message-ID: <87wpkn32h9.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <87h9br4h80.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> (Eric W. Biederman's message of "Fri, 15 Jul 2016 00:12:47 -0500")


In most code paths involving cgroup migration cgroup_threadgroup_rwsem
is taken.  There are two exceptions:

- remove_tasks_in_empty_cpuset calls cgroup_transfer_tasks
- vhost_attach_cgroups_work calls cgroup_attach_task_all

With cgroup_threadgroup_rwsem held it is guaranteed that cgroup_post_fork
and copy_cgroup_ns will reference the same css_set from the process calling
fork.

Without such an interlock there process after fork could reference one
css_set from it's new cgroup namespace and another css_set from
task->cgroups, which semantically is nonsensical.

Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces")
Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
---
 kernel/cgroup.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 66d2441f6db2..c99b0bcd2647 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2956,6 +2956,7 @@ int cgroup_attach_task_all(struct task_struct *from, struct task_struct *tsk)
 	int retval = 0;
 
 	mutex_lock(&cgroup_mutex);
+	percpu_down_write(&cgroup_threadgroup_rwsem);
 	for_each_root(root) {
 		struct cgroup *from_cgrp;
 
@@ -2970,6 +2971,7 @@ int cgroup_attach_task_all(struct task_struct *from, struct task_struct *tsk)
 		if (retval)
 			break;
 	}
+	percpu_up_write(&cgroup_threadgroup_rwsem);
 	mutex_unlock(&cgroup_mutex);
 
 	return retval;
@@ -4337,6 +4339,8 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
 
 	mutex_lock(&cgroup_mutex);
 
+	percpu_down_write(&cgroup_threadgroup_rwsem);
+
 	/* all tasks in @from are being moved, all csets are source */
 	spin_lock_bh(&css_set_lock);
 	list_for_each_entry(link, &from->cset_links, cset_link)
@@ -4365,6 +4369,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
 	} while (task && !ret);
 out_err:
 	cgroup_migrate_finish(&preloaded_csets);
+	percpu_up_write(&cgroup_threadgroup_rwsem);
 	mutex_unlock(&cgroup_mutex);
 	return ret;
 }
-- 
2.8.3

  parent reply	other threads:[~2016-07-15  5:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87h9br4h80.fsf@x220.int.ebiederm.org>
     [not found] ` <87h9br4h80.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15  5:15   ` [PATCH 1/3] cgroupns: Fix the locking in copy_cgroup_ns Eric W. Biederman
2016-07-15  5:16   ` Eric W. Biederman [this message]
2016-07-15  5:17   ` [PATCH 3/3] cgroupns: Only allow creation of hierarchies in the initial cgroup namespace Eric W. Biederman
     [not found]     ` <87r3av32g1.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 11:16       ` Tejun Heo
     [not found]         ` <20160715111659.GB3078-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-15 11:16           ` Eric W. Biederman
     [not found]             ` <8760s72lu5.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 11:35               ` [PATCH 1/3] cgroupns: Fix the locking in copy_cgroup_ns Eric W. Biederman
2016-07-15 11:35               ` [PATCH 2/3] cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns Eric W. Biederman
     [not found]                 ` <87mvlj16co.fsf_-_-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 11:58                   ` Tejun Heo
2016-07-15 11:36               ` [PATCH 3/3] cgroupns: Only allow creation of hierarchies in the initial cgroup namespace Eric W. Biederman
     [not found]                 ` <87h9br16b7.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 12:05                   ` Tejun Heo
     [not found]                     ` <20160715120501.GF3078-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-15 16:39                       ` Serge E. Hallyn
     [not found] ` <20160715111847.GC3078@mtj.duckdns.org>
     [not found]   ` <20160715111847.GC3078-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-15 11:34     ` [PATCH 0/3] cgroupns: Locking and semantic fixes Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wpkn32h9.fsf@x220.int.ebiederm.org \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.