linux-kernel - Confusing lockdep message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 May 2019 11:19:20 +0000
From:   "Koenig, Christian" <Christian.Koenig@....com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        LKML <linux-kernel@...r.kernel.org>
CC:     Daniel Vetter <daniel@...ll.ch>
Subject: Confusing lockdep message

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.