2022-05-10 00:33:28

by Byungchul Park

[permalink] [raw]
Subject: Re: [PATCH RFC v6 00/21] DEPT(Dependency Tracker)

On Mon, May 09, 2022 at 04:47:12PM -0400, Steven Rostedt wrote:
> On Mon, 9 May 2022 09:16:37 +0900
> Byungchul Park <[email protected]> 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'