summaryrefslogtreecommitdiff
path: root/lib/cordic.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2014-02-08 15:26:34 (GMT)
committerJiri Slaby <jslaby@suse.cz>2014-03-05 16:13:43 (GMT)
commit3e507fa19fea1d5423f4be675fd211c52f7c12c4 (patch)
tree38f24b7cb673ea50b90dab64e2b0e9b037dc2648 /lib/cordic.c
parent35fcf4dd2296b06b0ef042f203246dc73e6e3f02 (diff)
downloadlinux-fsl-qoriq-3e507fa19fea1d5423f4be675fd211c52f7c12c4.tar.xz
cgroup: fix locking in cgroup_cfts_commit()
commit 48573a893303986e3b0b2974d6fb11f3d1bb7064 upstream. cgroup_cfts_commit() walks the cgroup hierarchy that the target subsystem is attached to and tries to apply the file changes. Due to the convolution with inode locking, it can't keep cgroup_mutex locked while iterating. It currently holds only RCU read lock around the actual iteration and then pins the found cgroup using dget(). Unfortunately, this is incorrect. Although the iteration does check cgroup_is_dead() before invoking dget(), there's nothing which prevents the dentry from going away inbetween. Note that this is different from the usual css iterations where css_tryget() is used to pin the css - css_tryget() tests whether the css can be pinned and fails if not. The problem can be solved by simply holding cgroup_mutex instead of RCU read lock around the iteration, which actually reduces LOC. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizefan@huawei.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Diffstat (limited to 'lib/cordic.c')
0 files changed, 0 insertions, 0 deletions