On Mon, May 09, 2022 at 04:47:12PM -0400, Steven Rostedt wrote:
On Mon, 9 May 2022 09:16:37 +0900 Byungchul Park byungchul.park@lge.com wrote:
CASE 2.
lock L with depth n lock A lock_nested L' with depth n + 1 ... unlock L' unlock A unlock L
This case is allowed by Lockdep. This case is *NOT* allowed by DEPT cuz it's a *DEADLOCK*.
The following scenario would explain why CASE 2 is problematic.
THREAD X THREAD Y
lock L with depth n lock L' with depth n lock A lock A lock_nested L' with depth n + 1
I'm confused by what exactly you are saying is a deadlock above.
Are you saying that lock A and L' are inversed? If so, lockdep had better
Hi Steven,
Yes, I was talking about A and L'.
detect that regardless of L. A nested lock associates the the nesting with
When I checked Lockdep code, L' with depth n + 1 and L' with depth n have different classes in Lockdep.
That's why I said Lockdep cannot detect it. By any chance, has it changed so as to consider this case? Or am I missing something?
the same type of lock. That is, in lockdep nested tells lockdep not to trigger on the L and L' but it will not ignore that A was taken.
It will not ignore A but it would work like this:
THREAD X THREAD Y
lock Ln lock Ln lock A lock A lock_nested Lm lock_nested Lm
So, Lockdep considers this case safe, actually not tho.
Byungchul
-- Steve
lock_nested L'' with depth n + 1... ... unlock L' unlock L'' unlock A unlock A unlock L unlock L'