Skip to contentSkip to conversation

Patch "cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns" has been added to the 4.7-stable tree

PATCH [email protected] 1 participant 1 message Aug 18, 2016 Stable branch

lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns

to the 4.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
cgroupns-close-race-between-cgroup_post_fork-and-copy_cgroup_ns.patch
and it can be found in the queue-4.7 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From eedd0f4cbf5f3b81e82649832091e1d9d53f0709 Mon Sep 17 00:00:00 2001

From: "Eric W. Biederman" <[email protected]>
Date: Fri, 15 Jul 2016 06:35:51 -0500
Subject: cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns

From: Eric W. Biederman <[email protected]>

commit eedd0f4cbf5f3b81e82649832091e1d9d53f0709 upstream.

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.

Fixes a79a908fd2b0 ("cgroup: introduce cgroup namespaces")
---
 kernel/cgroup.c |    5 +++++
 1 file changed, 5 insertions(+)
kernel/cgroup.c +5 -0
@@ -2962,6 +2962,7 @@ int cgroup_attach_task_all(struct task_s
 	int retval = 0;
 
 	mutex_lock(&cgroup_mutex);
+	percpu_down_write(&cgroup_threadgroup_rwsem);
 	for_each_root(root) {
 		struct cgroup *from_cgrp;
 
@@ -2976,6 +2977,7 @@ int cgroup_attach_task_all(struct task_s
 		if (retval)
 			break;
 	}
+	percpu_up_write(&cgroup_threadgroup_rwsem);
 	mutex_unlock(&cgroup_mutex);
 
 	return retval;
@@ -4343,6 +4345,8 @@ int cgroup_transfer_tasks(struct cgroup
 
 	mutex_lock(&cgroup_mutex);
 
+	percpu_down_write(&cgroup_threadgroup_rwsem);
+
 	/* all tasks in @from are being moved, all csets are source */
 	spin_lock_irq(&css_set_lock);
 	list_for_each_entry(link, &from->cset_links, cset_link)
@@ -4371,6 +4375,7 @@ int cgroup_transfer_tasks(struct cgroup
 	} while (task && !ret);
 out_err:
 	cgroup_migrate_finish(&preloaded_csets);
+	percpu_up_write(&cgroup_threadgroup_rwsem);
 	mutex_unlock(&cgroup_mutex);
 	return ret;
 }

Patches currently in stable-queue which might be from [email protected] are

queue-4.7/cgroupns-fix-the-locking-in-copy_cgroup_ns.patch queue-4.7/cgroupns-only-allow-creation-of-hierarchies-in-the-initial-cgroup-namespace.patch queue-4.7/cgroupns-close-race-between-cgroup_post_fork-and-copy_cgroup_ns.patch