On Tue, Oct 14, 2025 at 05:03:58PM +1100, NeilBrown wrote:
> On Mon, 13 Oct 2025, Byungchul Park wrote:
> > On Fri, Oct 03, 2025 at 04:55:14PM +1000, NeilBrown wrote:
> > > On Thu, 02 Oct 2025, Byungchul Park wrote:
> > > > This document describes the concept and APIs of dept.
> > > >
> > >
> > > Thanks for the documentation. I've been trying to understand it.
> >
> > You're welcome. Feel free to ask me if you have any questions.
> >
> > > > +How DEPT works
> > > > +--------------
> > > > +
> > > > +Let's take a look how DEPT works with the 1st example in the section
> > > > +'Limitation of lockdep'.
> > > > +
> > > > + context X context Y context Z
> > > > +
> > > > + mutex_lock A
> > > > + folio_lock B
> > > > + folio_lock B <- DEADLOCK
> > > > + mutex_lock A <- DEADLOCK
> > > > + folio_unlock B
> > > > + folio_unlock B
> > > > + mutex_unlock A
> > > > + mutex_unlock A
> > > > +
> > > > +Adding comments to describe DEPT's view in terms of wait and event:
> > > > +
> > > > + context X context Y context Z
> > > > +
> > > > + mutex_lock A
> > > > + /* wait for A */
> > > > + folio_lock B
> > > > + /* wait for A */
> > > > + /* start event A context */
> > > > +
> > > > + folio_lock B
> > > > + /* wait for B */ <- DEADLOCK
> > > > + /* start event B context */
> > > > +
> > > > + mutex_lock A
> > > > + /* wait for A */ <- DEADLOCK
> > > > + /* start event A context */
> > > > +
> > > > + folio_unlock B
> > > > + /* event B */
> > > > + folio_unlock B
> > > > + /* event B */
> > > > +
> > > > + mutex_unlock A
> > > > + /* event A */
> > > > + mutex_unlock A
> > > > + /* event A */
> > > > +
> > >
> > > I can't see the value of the above section.
> > > The first section with no comments is useful as it is easy to see the
> > > deadlock being investigate. The section below is useful as it add
> > > comments to explain how DEPT sees the situation. But the above section,
> > > with some but not all of the comments, does seem (to me) to add anything
> > > useful.
> >
> > I just wanted to convert 'locking terms' to 'wait and event terms' by
> > one step. However, I can remove the section you pointed out that you
> > thought was useless.
>
> But it seems you did it in two steps???
>
> If you think the middle section with some but not all of the comments
> adds value (And maybe it does - maybe I just haven't seen it yet), the
> please explain what value is being added at each step.
>
> It is currently documented as:
>
> +Adding comments to describe DEPT's view in terms of wait and event:
>
> then
>
> +Adding more supplementary comments to describe DEPT's view in detail:
>
> Maybe if you said more DEPT's view so at this point so that when we see
> the supplementary comments, we can understand how they relate to DEPT's
> view.
As you pointed out, I'd better remove the middle part so as to simplify
it. It doesn't give much information I also think.
> > > > +
> > > > + context X context Y context Z
> > > > +
> > > > + mutex_lock A
> > > > + /* might wait for A */
> > > > + /* start to take into account event A's context */
> > >
> > > What do you mean precisely by "context".
> >
> > That means one of task context, irq context, wq worker context (even
> > though it can also be considered as task context), or something.
>
> OK, that makes sense. If you provide this definition for "context"
> before you use the term, I think that will help the reader.
Thank you. I will add it.
> > > If the examples that follow It seems that the "context" for event A
> > > starts at "mutex lock A" when it (possibly) waits for a mutex and ends
> > > at "mutex unlock A" - which are both in the same process. Clearly
> > > various other events that happen between these two points in the same
> > > process could be seen as the "context" for event A.
> > >
> > > However event B starts in "context X" with "folio_lock B" and ends in
> > > "context Z" or "context Y" with "folio_unlock B". Is that right?
> >
> > Right.
> >
> > > My question then is: how do you decide which, of all the event in all
> > > the processes in all the system, between the start[S] and the end[E] are
> > > considered to be part of the "context" of event A.
> >
> > DEPT can identify the "context" of event A only *once* the event A is
> > actually executed, and builds dependencies between the event and the
> > recorded waits in the "context" of event A since [S].
>
> So a dependency is an ordered set of pairs of "context" and "wait" or
I don't get what you were trying to tell here. FWIW, DEPT focuses on
*event* contexts and, within each event context, it tracks pairs of
waits that appears since [S] and the interesting event that identifies
the event context.
> "context" and "event". "wait"s and "event"s are linked by some abstract
> identifier for the event (like lockdep's lock classes).
Yeah, kind of.
> How are the contexts abstracted. Is it just "same" or "different"
I don't get this. Can you explain in more detail?
Byungchul
> I'll try reading the document again and see how much further I get.
>
> Thanks,
> NeilBrown
