diff options
author | 2012-11-19 08:13:37 -0800 | |
---|---|---|
committer | 2012-11-19 08:13:37 -0800 | |
commit | b8a2df6a5b576d04f78f54abf254c283527d8bbc (patch) | |
tree | 6a49e4105d3bb3d813378d72ebf67c08d719d0de /scripts/checkstack.pl | |
parent | cgroup: simplify cgroup_load_subsys() failure path (diff) | |
download | linux-dev-b8a2df6a5b576d04f78f54abf254c283527d8bbc.tar.xz linux-dev-b8a2df6a5b576d04f78f54abf254c283527d8bbc.zip |
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 'scripts/checkstack.pl')
0 files changed, 0 insertions, 0 deletions