IRQ标志状态追踪¶
- 作者:
由Ingo Molnar <mingo@redhat.com>开始
“irq-flags 追踪”特性“追踪”硬中断和软中断状态，即，它为感兴趣的子系统提供了一个机会，以便在内核中发生的每个硬中断关闭/硬中断开启、软中断关闭/软中断开启事件时收到通知。
CONFIG_PROVE_SPIN_LOCKING和CONFIG_PROVE_RW_LOCKING需要CONFIG_TRACE_IRQFLAGS_SUPPORT才能由通用锁调试代码提供。否则，架构上只会提供CONFIG_PROVE_MUTEX_LOCKING和CONFIG_PROVE_RWSEM_LOCKING - 这些是在IRQ上下文中不使用的锁定API。（rwsem的例外情况已解决）
对此的架构支持肯定不属于“琐碎”类别，因为许多底层汇编代码都处理irq-flags状态更改。但是，可以以相当简单且无风险的方式启用架构的irq-flags-tracing。
想要支持此功能的架构首先需要进行一些代码组织更改
在其架构级别的Kconfig文件中添加并启用TRACE_IRQFLAGS_SUPPORT
然后还需要进行一些功能更改才能实现irq-flags-tracing支持
在底层入口代码中添加（构建条件）对trace_hardirqs_off()/trace_hardirqs_on()函数的调用。锁验证器密切关注“真实”irq-flags是否与“虚拟”irq-flags状态匹配，如果两者不匹配，则会大声抱怨（并关闭自身）。通常，架构支持irq-flags-tracing的大部分时间都花在这个状态上：查看lockdep抱怨，尝试找出我们尚未覆盖的汇编代码，修复并重复。一旦系统启动并工作，并且在irq-flags-tracing函数中没有lockdep抱怨，则架构支持就完成了。
如果该架构具有非屏蔽中断，则需要通过lockdep_off()/lockdep_on()将这些中断从irq-tracing[和锁验证]机制中排除。
一般来说，在架构中拥有不完整的irq-flags-tracing实现没有风险：lockdep会检测到这一点并关闭自身。也就是说，锁验证器仍然是可靠的。由于irq-tracing错误应该不会发生崩溃。（除非汇编更改通过修改不应该修改的条件或寄存器来破坏其他代码）