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@xxxxxxx> 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'
