Can we start DEPT as an AI review prompt, by documenting DEPT's
dependency tracking model and false positive elimination rules as a
carefully crafted prompt?
While DEPT can identify deadlock issues beyond lockdep's capabilities,
it is hard to enable in automated testing; without fine-grained
annotations it can produce a high rate of false positives, and verifying
them requires significant human effort.
The open source AI Review Prompt has locking.md file [1] that teaches
the AI how to review locks and detect misuse.
If we can write a review prompt for DEPT in a similar manner and have
the AI do the deadlock detection and false positive elimination, I think
we could identify those problems more effectively with much less human
effort.
[1]
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/locking.md
--
Cheers,
Harry / Hyeonggon
On 12/5/25 4:18 PM, Byungchul Park wrote:
I'm happy to see that DEPT reported real problems in practice:
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/all/[email protected]/
I’ve added documentation describing DEPT — this should help you
understand what DEPT is and how it works. You can use DEPT simply by
enabling CONFIG_DEPT and checking dmesg at runtime.
---
Hi Linus and folks,
I’ve been developing a tool to detect deadlock possibilities by tracking
waits/events — rather than lock acquisition order — to cover all the
synchronization mechanisms. To summarize the design rationale, starting
from the problem statement, through analysis, to the solution:
CURRENT STATUS
--------------
Lockdep tracks lock acquisition order to identify deadlock conditions.
Additionally, it tracks IRQ state changes — via {en,dis}able — to
detect cases where locks are acquired unintentionally during
interrupt handling.
PROBLEM
-------
Waits and their associated events that are never reachable can
eventually lead to deadlocks. However, since Lockdep focuses solely
on lock acquisition order, it has inherent limitations when handling
waits and events.
Moreover, by tracking only lock acquisition order, Lockdep cannot
properly handle read locks or cross-event scenarios — such as
wait_for_completion() and complete() — making it increasingly
inadequate as a general-purpose deadlock detection tool.
SOLUTION
--------
Once again, waits and their associated events that are never
reachable can eventually lead to deadlocks. The new solution, DEPT,
focuses directly on waits and events. DEPT monitors waits and events,
and reports them when any become unreachable.
DEPT provides:
* Correct handling of read locks.
* Support for general waits and events.
* Continuous operation, even after multiple reports.
* Simple, intuitive annotation APIs.
There are still false positives, and some are already being worked on
for suppression. Especially splitting the folio class into several
appropriate classes e.g. block device mapping class and regular file
mapping class, is currently under active development by me and Yeoreum
Yun.
Anyway, these efforts will need to continue for a while, as we’ve seen
with lockdep over two decades. DEPT is tagged as EXPERIMENTAL in
Kconfig — meaning it’s not yet suitable for use as an automation tool.
However, for those who are interested in using DEPT to analyze complex
synchronization patterns and extract dependency insights, DEPT would be
a great tool for the purpose.
