]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
cgroupns: Fix the locking in copy_cgroup_ns
authorEric W. Biederman <ebiederm@xmission.com>
Fri, 15 Jul 2016 11:35:24 +0000 (06:35 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 20 Aug 2016 16:10:58 +0000 (18:10 +0200)
commitffdc59dda08cddf1b8402c33e7d1e9a75f0ea749
treee1dee8ed865bb188ae02eb30ca19be877e48c79d
parentbc7db37cf45271a0ccf2e71a5417d18f9be4672d
cgroupns: Fix the locking in copy_cgroup_ns

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