Hi Harry, On Sat, May 23, 2026 at 2:33 PM Harry Yoo <[email protected]> wrote: > > 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
I think this is an excellent idea, Harry. I've previously experimented with running DEPT alongside syzkaller fuzzing, and many hung tasks missed by lockdep are caught by DEPT, but the resulting high volume of reports makes it easy for issues to get lost in the massive log output. Sorting through that output manually is a huge bottleneck, so leveraging a well-crafted AI prompt to triage the warnings and filter out the false positives would be incredibly valuable. Leveraging an AI prompt to triage these warnings would be incredibly valuable. I'd be happy to help translate DEPT's tracking model into specific rules for reducing false positives and establishing solid filtering patterns. > 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. Best regards, Yunseong
