]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
locking/lockdep: Fix OOO unlock when hlocks need merging
authorImre Deak <imre.deak@intel.com>
Fri, 24 May 2019 20:15:08 +0000 (23:15 +0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 26 Jul 2019 07:12:29 +0000 (09:12 +0200)
commit90b05e4ee4f6d40d2ee69aa899e0a6c99a36cb82
tree9a10c7d692a01092e0a064918f292cec3bcff5b5
parenta2b46e78fa4c60142477626b4be53001f7d7a79b
locking/lockdep: Fix OOO unlock when hlocks need merging

[ Upstream commit 8c8889d8eaf4501ae4aaf870b6f8f55db5d5109a ]

The sequence

static DEFINE_WW_CLASS(test_ww_class);

struct ww_acquire_ctx ww_ctx;
struct ww_mutex ww_lock_a;
struct ww_mutex ww_lock_b;
struct mutex lock_c;
struct mutex lock_d;

ww_acquire_init(&ww_ctx, &test_ww_class);

ww_mutex_init(&ww_lock_a, &test_ww_class);
ww_mutex_init(&ww_lock_b, &test_ww_class);

mutex_init(&lock_c);

ww_mutex_lock(&ww_lock_a, &ww_ctx);

mutex_lock(&lock_c);

ww_mutex_lock(&ww_lock_b, &ww_ctx);

mutex_unlock(&lock_c); (*)

ww_mutex_unlock(&ww_lock_b);
ww_mutex_unlock(&ww_lock_a);

ww_acquire_fini(&ww_ctx);

triggers the following WARN in __lock_release() when doing the unlock at *:

DEBUG_LOCKS_WARN_ON(curr->lockdep_depth != depth - 1);

The problem is that the WARN check doesn't take into account the merging
of ww_lock_a and ww_lock_b which results in decreasing curr->lockdep_depth
by 2 not only 1.

Note that the following sequence doesn't trigger the WARN, since there
won't be any hlock merging.

ww_acquire_init(&ww_ctx, &test_ww_class);

ww_mutex_init(&ww_lock_a, &test_ww_class);
ww_mutex_init(&ww_lock_b, &test_ww_class);

mutex_init(&lock_c);
mutex_init(&lock_d);

ww_mutex_lock(&ww_lock_a, &ww_ctx);

mutex_lock(&lock_c);
mutex_lock(&lock_d);

ww_mutex_lock(&ww_lock_b, &ww_ctx);

mutex_unlock(&lock_d);

ww_mutex_unlock(&ww_lock_b);
ww_mutex_unlock(&ww_lock_a);

mutex_unlock(&lock_c);

ww_acquire_fini(&ww_ctx);

In general both of the above two sequences are valid and shouldn't
trigger any lockdep warning.

Fix this by taking the decrement due to the hlock merging into account
during lock release and hlock class re-setting. Merging can't happen
during lock downgrading since there won't be a new possibility to merge
hlocks in that case, so add a WARN if merging still happens then.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: ville.syrjala@linux.intel.com
Link: https://lkml.kernel.org/r/20190524201509.9199-1-imre.deak@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
kernel/locking/lockdep.c