What Lockdep Does and Doesn't
summary
Lockdep tracks lock acquisition order and IRQ enable/disable state to spot ordering-based deadlocks but turns off after detection because its internal graph is not reusable, and it produces persistent false positives that block further analysis. It misses deadlocks caused by unreachable waits/events and cannot handle read-locks or cross-event pairs like wait_for_completion()/complete(). A new tool, Dept, tracks waits and events and reports unreachable events instead, demonstrating catch of deadlocks Lockdep misses though it currently has some false positives.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 0:26What Lockdep does
- 3:01RCU usage
- 5:06Log dependence correctness
- 12:40Examples
- 13:22Depth
- 14:01Conclusion
related talks
35mRecursive Read Deadlocks and Where to Find Them
20mDLOS: Effective Static Detection of Deadlocks in OS Kernels
24mStatic Deadlock Detection for Go
54mCatching Real-time Safety Violations in C++
27mAutoLock: Why Cache Attacks on ARM Are Harder Than You Think
48mDPTrace: Dual Purpose Trace for Exploitability Analysis of Program Crashes
48mCapturing 0Day Exploits With Perfectly Placed Hardware Traps
01h 02mLock-free programming for real-time systems