summaryrefslogtreecommitdiff
path: root/security/device_cgroup.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2012-11-19 20:13:37 +0400
committerTejun Heo <tj@kernel.org>2012-11-19 20:13:37 +0400
commitb8a2df6a5b576d04f78f54abf254c283527d8bbc (patch)
tree6a49e4105d3bb3d813378d72ebf67c08d719d0de /security/device_cgroup.c
parentd19e19de48aa0b90c56cd93c8a46ebac46273429 (diff)
downloadlinux-b8a2df6a5b576d04f78f54abf254c283527d8bbc.tar.xz
cgroup: use mutex_trylock() when grabbing i_mutex of a new cgroup directory
All cgroup directory i_mutexes nest outside cgroup_mutex; however, new directory creation is a special case. A new cgroup directory is created while holding cgroup_mutex. Populating the new directory requires both the new directory's i_mutex and cgroup_mutex. Because all directory i_mutexes nest outside cgroup_mutex, grabbing both requires releasing cgroup_mutex first, which isn't a good idea as the new cgroup isn't yet ready to be manipulated by other cgroup opreations. This is worked around by grabbing the new directory's i_mutex while holding cgroup_mutex before making it visible. As there's no other user at that point, grabbing the i_mutex under cgroup_mutex can't lead to deadlock. cgroup_create_file() was using I_MUTEX_CHILD to tell lockdep not to worry about the reverse locking order; however, this creates pseudo locking dependency cgroup_mutex -> I_MUTEX_CHILD, which isn't true - all directory i_mutexes are still nested outside cgroup_mutex. This pseudo locking dependency can lead to spurious lockdep warnings. Use mutex_trylock() instead. This will always succeed and lockdep doesn't create any locking dependency for it. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizefan@huawei.com>
Diffstat (limited to 'security/device_cgroup.c')
0 files changed, 0 insertions, 0 deletions