* Patch "cgroupns: Fix the locking in copy_cgroup_ns" has been added to the 4.7-stable tree
@ 2016-08-18 10:57 gregkh
0 siblings, 0 replies; only message in thread
From: gregkh @ 2016-08-18 10:57 UTC (permalink / raw)
To: ebiederm, gregkh, tj; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
cgroupns: Fix the locking in 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-fix-the-locking-in-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 <stable@vger.kernel.org> know about it.
>From 7bd8830875bfa380c68f390efbad893293749324 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Fri, 15 Jul 2016 06:35:24 -0500
Subject: cgroupns: Fix the locking in copy_cgroup_ns
From: Eric W. Biederman <ebiederm@xmission.com>
commit 7bd8830875bfa380c68f390efbad893293749324 upstream.
If "clone(CLONE_NEWCGROUP...)" is called it results in a nice lockdep
valid splat.
In __cgroup_proc_write the lock ordering is:
cgroup_mutex -- through cgroup_kn_lock_live
cgroup_threadgroup_rwsem
In copy_process the guts of clone the lock ordering is:
cgroup_threadgroup_rwsem -- through threadgroup_change_begin
cgroup_mutex -- through copy_namespaces -- copy_cgroup_ns
lockdep reports some a different call chains for the first ordering of
cgroup_mutex and cgroup_threadgroup_rwsem but it is harder to trace.
This is most definitely deadlock potential under the right
circumstances.
Fix this by by skipping the cgroup_mutex and making the locking in
copy_cgroup_ns mirror the locking in cgroup_post_fork which also runs
during fork under the cgroup_threadgroup_rwsem.
Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -6309,14 +6309,11 @@ struct cgroup_namespace *copy_cgroup_ns(
if (!ns_capable(user_ns, CAP_SYS_ADMIN))
return ERR_PTR(-EPERM);
- mutex_lock(&cgroup_mutex);
+ /* It is not safe to take cgroup_mutex here */
spin_lock_irq(&css_set_lock);
-
cset = task_css_set(current);
get_css_set(cset);
-
spin_unlock_irq(&css_set_lock);
- mutex_unlock(&cgroup_mutex);
new_ns = alloc_cgroup_ns();
if (IS_ERR(new_ns)) {
Patches currently in stable-queue which might be from ebiederm@xmission.com 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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-08-18 10:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-18 10:57 Patch "cgroupns: Fix the locking in copy_cgroup_ns" has been added to the 4.7-stable tree gregkh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox