diff options
author | Waiman Long <longman@redhat.com> | 2021-03-18 13:28:14 -0400 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2021-03-19 12:13:10 +0100 |
commit | 8c52cca04f97a4c09ec2f0bd8fe6d0cdf49834e4 (patch) | |
tree | 75d00f8605bfc8e41c1e9e298a7bc7414e56bcac /include/linux/lockdep.h | |
parent | aa3a5f31877e5dc131cc286ce707413d441c8375 (diff) | |
download | linux-8c52cca04f97a4c09ec2f0bd8fe6d0cdf49834e4.tar.gz linux-8c52cca04f97a4c09ec2f0bd8fe6d0cdf49834e4.tar.bz2 linux-8c52cca04f97a4c09ec2f0bd8fe6d0cdf49834e4.zip |
locking/locktorture: Fix incorrect use of ww_acquire_ctx in ww_mutex test
The ww_acquire_ctx structure for ww_mutex needs to persist for a complete
lock/unlock cycle. In the ww_mutex test in locktorture, however, both
ww_acquire_init() and ww_acquire_fini() are called within the lock
function only. This causes a lockdep splat of "WARNING: Nested lock
was not taken" when lockdep is enabled in the kernel.
To fix this problem, we need to move the ww_acquire_fini() after
the ww_mutex_unlock() in torture_ww_mutex_unlock(). This is done by
allocating a global array of ww_acquire_ctx structures. Each locking
thread is associated with its own ww_acquire_ctx via the unique thread
id it has so that both the lock and unlock functions can access the
same ww_acquire_ctx structure.
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210318172814.4400-6-longman@redhat.com
Diffstat (limited to 'include/linux/lockdep.h')
0 files changed, 0 insertions, 0 deletions