lkml.org 
[lkml]   [2022]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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 <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'

\
 
 \ /
  Last update: 2022-05-10 01:45    [W:0.501 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site