* Confusing lockdep message
@ 2019-05-20 11:19 Koenig, Christian
2019-05-20 11:38 ` Koenig, Christian
0 siblings, 1 reply; 3+ messages in thread
From: Koenig, Christian @ 2019-05-20 11:19 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Will Deacon, LKML; +Cc: Daniel Vetter
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Confusing lockdep message
2019-05-20 11:19 Confusing lockdep message Koenig, Christian
@ 2019-05-20 11:38 ` Koenig, Christian
2019-05-20 15:50 ` Daniel Vetter
0 siblings, 1 reply; 3+ messages in thread
From: Koenig, Christian @ 2019-05-20 11:38 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Will Deacon, LKML; +Cc: Daniel Vetter
Please ignore this mail,
I've fixed the double unlock and lockdep is still complaining about the
nested locking, so I'm actually facing multiple issues here.
Sorry to waste your time,
Christian.
Am 20.05.19 um 13:19 schrieb Christian König:
> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Confusing lockdep message
2019-05-20 11:38 ` Koenig, Christian
@ 2019-05-20 15:50 ` Daniel Vetter
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Vetter @ 2019-05-20 15:50 UTC (permalink / raw)
To: Koenig, Christian; +Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, LKML
On Mon, May 20, 2019 at 1:38 PM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Please ignore this mail,
>
> I've fixed the double unlock and lockdep is still complaining about the
> nested locking, so I'm actually facing multiple issues here.
The way we model the ww-mutex stuff is that the acquire-ctx is treated
as a lockdep lock, and then we require that one if you take two or
more ww-mutexes (the nested locking stuff lockdep complains about).
So you already hold a ww-mutex while trying to get a 2nd one, without
holding a ww-mutex acquire ctx ticket. Could be a ww-mutex you forgot
to unlock somewhere.
-Daniel
>
> Sorry to waste your time,
> Christian.
>
> Am 20.05.19 um 13:19 schrieb Christian König:
> > 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.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-05-20 15:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-20 11:19 Confusing lockdep message Koenig, Christian
2019-05-20 11:38 ` Koenig, Christian
2019-05-20 15:50 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).