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.p...@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'
