Confusing lockdep message

From: Koenig, Christian
Date: Mon May 20 2019 - 07:21:47 EST


Hi guys,

writing the usual suspects about locking/lockdep stuff and also Daniel
in CC because he might have stumbled over this as well.

It took me a while to figuring out what the heck lockdep was complaining
about. The relevant dmesg was the following:
> [Â 145.623005] ==================================
> [Â 145.623094] WARNING: Nested lock was not taken
> [Â 145.623184] 5.0.0-rc1+ #144 Not tainted
> [Â 145.623261] ----------------------------------
> [Â 145.623351] amdgpu_test/1411 is trying to lock:
> [Â 145.623442] 0000000098a1c4d3 (reservation_ww_class_mutex){+.+.},
> at: ttm_eu_reserve_buffers+0x46e/0x910 [ttm]
> [Â 145.623651]
> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ but this task is not holding:
> [Â 145.623758] reservation_ww_class_acquire
> [Â 145.623836]
> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ stack backtrace:
> [Â 145.623924] CPU: 4 PID: 1411 Comm: amdgpu_test Not tainted
> 5.0.0-rc1+ #144
> [Â 145.624058] Hardware name: System manufacturer System Product
> Name/PRIME X399-A, BIOS 0808 10/12/2018
> [Â 145.624234] Call Trace:
> ...

The problem is now that the message is very confusion because the issue
was *not* that I tried to acquire a lock, but rather that I accidentally
released a lock twice.

Now releasing a lock twice is a rather common mistake and I'm really
surprised that I didn't get that pointed out by lockdep immediately.

Additional to that I'm pretty sure that this used to work correctly
sometimes in the past, so I'm either hitting a rare corner case or this
broke just recently.

Anyway can somebody take a look? I can try to provide a test case if
required.

Thanks in advance,
Christian.