lockdep 与锁依赖检查
这页讲的是：很多锁问题不是每次都必现死锁，而是系统里已经悄悄形成了危险的加锁顺序图，只是暂时还没撞上。学这页的重点，是理解 lockdep 更像一套运行时锁关系审计器：它不替你修 bug，但会尽量早地指出“这条锁依赖图已经很危险了”。
这块是什么
lockdep 与锁依赖检查，讲的是 Linux 怎样在运行时追踪锁的获取关系、上下文限制和依赖顺序，尽早发现可能导致死锁、错误嵌套或不合法上下文使用的模式。它关注的是“锁关系图有没有已经变危险”，而不是等系统真卡死后再猜哪里错了。
可以把它理解成：不是等城市交通真的堵死以后才承认路网设计有问题，而是提前画出路口依赖图，发现某些环路一旦同时出现就迟早会出大堵塞。
它负责什么
追踪锁获取顺序
- 很多死锁不是某把锁本身坏，而是获取顺序形成了环
- lockdep 关注谁在谁后面拿、哪些组合曾经出现过
- 让潜在循环依赖更早暴露
- 把“加锁顺序”正式建模出来
检查上下文合法性
- 不同锁和不同上下文之间常有硬约束
- 某些环境里不能拿某类会睡眠的锁
- lockdep 帮忙指出这种不合法组合
- 让“这地方本来就不该这样拿锁”更容易被看见
把偶发并发 bug 提前成告警
- 很多锁顺序问题平时可能并不立即爆
- 但运行时一旦关系图形成危险模式，就值得告警
- 让开发者在死锁发生前就看到趋势
- 把后验故障转成更早的前瞻性检查
为什么它不是“调试时可有可无的小插件”
| 如果想得太简单 | 会怎样 | 真正关键在哪 |
|---|
| 觉得只要系统没死锁就说明没问题 | 会忽略很多危险顺序只是暂时还没被触发。 | lockdep 的价值正在于比事故更早发现结构性问题。 |
| 把它当普通日志打印 | 会低估它其实在维护一张锁依赖关系图。 | 它不是记流水账，而是在分析模式。 |
| 觉得有单元测试就够了 | 会漏掉并发时序问题往往和覆盖率没有线性关系。 | 锁图错误常需要专门的运行时关系检查。 |
| 只盯死锁本身 | 会错过上下文违规、错误嵌套等也同样危险。 | 锁正确性不只是不死锁，还包括用法边界合法。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| lockdep | 运行时追踪和分析锁依赖关系的检查机制。 |
| 依赖图 | 谁先拿哪把锁、后拿哪把锁，这些关系会形成一张图。 |
| 循环依赖 | 如果锁顺序图形成环，就意味着潜在死锁风险大增。 |
| 上下文违规 | 某些锁在某些执行环境里本来就不该被拿到。 |
| 早期告警 | 真正价值常在系统还没挂死前，就先指出模式已经不健康。 |
为什么重要
- 它解释了为什么锁 bug 很多时候不能只靠“出了问题再 dump 栈”去解决。
- 很多最棘手的并发问题，真正难点在于依赖关系图已经悄悄变坏，但现场还不稳定复现。
- 理解这层后，你会更容易把锁顺序、执行上下文和调试策略放在一起看。
- 它让你看到：并发调试不只是看某一把锁，还要看整个系统的拿锁网络是不是已经危险。
常见误解
- 误解一：只要没复现死锁，报警就是误报。实际上很多报警是在提前指出危险结构。
- 误解二：lockdep 只和锁顺序有关。实际上上下文合法性和嵌套关系也很重要。
- 误解三：这是调试工具，不影响设计。实际上知道它在看什么，也会反过来影响你怎么组织锁层级。
它不负责什么
- 它不替你设计正确锁协议，只是在运行时尽量发现危险模式。
- 它不解决对象生命周期和引用安全，那是另一类并发正确性问题。
- 它不保证生产环境永远开启或覆盖到所有路径，仍然离不开设计上的自觉和测试。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| spinlock / mutex / rwsem | 它检查的很多对象正是这些常用锁原语在真实系统里形成的顺序网络。 |
| preemption 与上下文 | 某些锁能不能在当前上下文里获取，常和抢占、睡眠能力和执行环境直接相关。 |
| 测试与调试 | 它更像并发正确性的专门调试视角，帮助把偶发问题前移到更可见的阶段。 |
| refcount_t | 两者都在兜底并发正确性，但一个盯锁依赖，一个盯对象持有边界。 |
读完这页后，你应该能回答
- 为什么 lockdep 的价值常在“系统还没死锁之前”就指出依赖结构已经危险？
- 为什么锁正确性不只是不形成环，还包括上下文合法性和嵌套边界？
- 为什么理解 lockdep 在看什么，会反过来帮助你设计更清楚的锁层级？
后面适合继续问：lockdep 和简单的死锁复现日志有什么本质区别？为什么某些报警虽然没复现死锁，仍值得认真修？如果一个对象既有生命周期问题又有锁顺序问题，应该怎么在脑子里把两类错误分开看？