On Mon, Jul 06, 2026 at 03:19:10PM +0900, Byungchul Park wrote:
> Makes dept able to track PG_locked waits and events, which will be
> useful in practice. See the following link that shows dept worked with
> PG_locked and detected real issues in practice:
>
>
> https://lore.kernel.org/lkml/[email protected]/
> @@ -219,6 +220,7 @@ struct page {
> struct page *kmsan_shadow;
> struct page *kmsan_origin;
> #endif
> + struct dept_ext_wgen pg_locked_wgen;
> } _struct_page_alignment;
I may not understand this quite correctly, but I think that tracking
PG_locked dependencies in the struct page has both false positive and
false negative problems.
Imagine we have a file mapping M1 containing folio F1 at index 0 and F2
at index 1. It is correct locking order to lock F1 before locking F2
(for example when doing writeback). Later, M1 has its folios reclaimed
and returned to the free pool. Then each is added to mapping M2, this
time with folio F2 at index 8 and F1 at index 9. Now the correct order
to lock these folios in the order F2 followed by F1.
I don't see a part of this patch where we clear pg_locked_wgen when the
page is returned to the page allocator. Maybe I missed that.
I think we should be tracking PG_locked dependencies in the owner
of the folio. For files, that would be in the struct address_space.
For anon memory, I think that's in the anon_vma, but if somebody told
me it was in some other structure, I wouldn't argue with them.
This requires slightly more complexity than lockdep currently has.
We don't want to use a lockdep class for each folio, obviously. So we
need something to say "I already have folio F1 locked, is it OK to lock
folio F2?". Essentially figuring out how we can track all folios in a
given mapping the same way, and making sure that we don't deadlock on
folios in the same mapping.
If F1 and F2 are in different mappings, it's not a deadlock if F1 is in a
filesystem mapping and F2 is in its backing dev. It's also not a deadlock
if F1 and F2 are both filesystem folios and the inodes are both locked.
See vfs_lock_two_folios() in fs/remap_range.c.
I have much less knowledge about anonymous memory locking order.
Maybe it doesn't happen. Or about locking one anon and one file folio.
For slab memory, we don't sleep on PG_locked (it's used as a spinlock bit).
For other kinds of memory ... I don't know. Page migration is fun.
