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/aR3WHf9QZ_dizNun@casper.infradead.org/?utm_sourc...

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/20200127150024.GN1183@dhcp22.suse.cz/ 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