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/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/ (local)
    https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/ (local)
    https://lore.kernel.org/all/b6e00e77-4a8c-4e05-ab79-266bf05fcc2d@igalia.com/ (local)

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.

quoted

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.