Re: [PATCH v19 00/40] DEPT(DEPendency Tracker)

On Thu, Aug 20, 2026 at 06:51:08PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 20, 2026 at 07:16:05PM +0200, David Hildenbrand (Arm) wrote:
> > > Consider this real deadlock pattern that lockdep cannot detect:
> > >
> > >    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
> >
> > But that really just boils down to folio lock being implemented as a PG_lock +
> > some advanced wait mechanism. And we must do that because of lack of bits in
> > struct page.
> >
> > Willy mentioned in a previous version [1]: "I don't think it makes sense to
> > track lock state in the page (nor folio).  Partly because there's just so many
> > of them, but also because the locking rules don't really apply to individual
> > folios so much as they do to the mappings (or anon_vmas) that contain folios."
> >
> > Given that lockdep is a debug feature, and we will at some point allocate struct
> > folio separately, I assume we could just squeeze a "struct lockdep_map" in there
> > in such debug configs and the world would not collapse.
> >
> > Doing that today (one "struct lockdep_map" in each "struct page") wouldn't work
> > as mm_zero_struct_page() would not expect such large "struct page". But
> > conceptually, for a debug kernel with a special CONFIG_LOCKDEP_PAGE_LOCK, maybe
> > that would already be ok and we could just do that (and optimize it as we
> > allocate folios separately).
> >
> > Not that it's ideal, but for a debug feature to at least check PG_lock, probably
> > an easier way to achieve it than some completely new infrastructure.
> >
> > Now, Willy said "locking rules don't really apply to individual folios", I
> > wonder if that could just help to also let lockdep check PG_lock with less
> > metadata? (didn't fully wrap my head around the implications)
> >
> > [1]
> > https://lore.kernel.org/all/[email protected]/?utm_source=chatgpt.com
> 
> There are a few things going on that make PG_lock special.  Let me try
> to explain again, only better this time.
> 
> 1. The current lifetime of a struct page is the lifetime of the system.
> But the semantics of its PG_lock bit change each time it is freed and
> allocated.

Yes, it's a classification issue that is very important.

> 2. The position of PG_lock in the locking hierarchy only depend on
> what the folio is currently being used for.  That is, all folios in
> a given xfs inode behave exactly the same from a locking perspective.

You are exactly explaining what the classification means.  Perfect.

> There's no need to build up state about how each PG_lock is used;
> they can all share.  Arguably all xfs file inodes are the same as

Right.  That's why DEPT doesn't use a full map in each page but just
uses a timestamp in each.  For the classification, DEPT uses a few
classes for folio, using global maps:

   1. folios in mm paths
   2. folios in block device buffer (meta data)
   3. folios in regular file cache

However, yes.  I bet you could be a big help when classifying folios
more presicely according to its usage.  But the current classification
is still a good start I think.

> each other (directory inodes might be different from file inodes),
> so we might want to go further than telling DEPT that "this folio
> belongs to this inode" and go to "this folio belongs to this xfs file
> inode".

Totally agree.

> 3. PG_lock can be taken in task context then released in interrupt
> context.  For full points, we need to mark the exact point at which
> we submit the folio for read.  Otherwise we can get into the situation
> alluded to by f2c817bed58d and better discussed at
> https://lore.kernel.org/linux-mm/[email protected]/
> where we have the folio locked but haven't yet submitted it for I/O
> so it doesn't matter how long we wait, it will never come unlocked.

Interesting.  

The following abstraction might make DEPT work with it.  For example:

   Annotate the point submitting IO as an event for the folio_lock() to
   be released.  That way, the issue above can be detected by DEPT.

Again, DEPT can do every thing we need w.r.t. deadlock.

	Byungchul