Linux 记一次spin_lock死锁优化经验

From 程序员秘书

死锁是很常见的一种内核故障。

最简单也是最常见的，就是如果一个task在已经持有某个锁的情况下，再次尝试获取同一个锁，就会形成死锁局面。发生死锁的场景有很多，常见的情况可能有，可能是在同一个task中锁使用不当；也可能是两个task有资源竞争和依赖，形成互锁互等；也可能是某个task拿了锁后又被某个中断抢占，之后又在等拿相同的锁。

最近刚分析和处理了一个死锁问题，就是一个task和一个中断拿相同锁出现的死锁问题，最后是通过将替换拿锁接口函数解决的。主要是涉及到spin_trylock_irq() 和 spin_trylock() 这两个函数的使用场景和差别，所以记录学习一下。

spin_trylock_irq() 和 spin_trylock() 都是Linux内核中用于尝试获取自旋锁的函数，但它们在使用场景和行为上有所区别，主要体现在对中断的处理上。下面是对这两个函数的深入解析：

spin_trylock()

• 功能：spin_trylock() 是一个非阻塞的自旋锁获取函数，它尝试立即获取自旋锁。如果锁已被其他CPU持有，该函数会立即返回失败（通常返回0），而不会让调用者进入等待状态。这适用于那些无法承受阻塞开销或不适合睡眠的上下文。
• 中断处理：调用 spin_trylock() 时，当前CPU的中断状态不变。也就是说，如果在中断上下文中调用此函数，中断仍然保持禁止状态；而在进程上下文中调用，则中断是启用的。

spin_trylock_irq()

• 功能：spin_trylock_irq() 与 spin_trylock() 类似，也是尝试立即获取自旋锁，如果不能立即获取则返回失败。但是，它还额外包含了一层对中断的管理。
• 中断处理：在尝试获取锁之前，spin_trylock_irq() 会临时禁用本地中断（如果之前是启用状态），并在操作完成后恢复中断的原始状态。这意味着，无论是在中断上下文还是进程上下文中调用，它都会确保在尝试获取锁期间中断是被禁止的，从而避免了在获取锁的过程中被中断打断的复杂性。这种设计提高了锁操作的原子性和安全性，但需要注意的是，它可能会在某些对中断响应时间敏感的场景中引入延迟。

联系与区别总结

• 联系：两者都是非阻塞式的自旋锁获取操作，不成功即返回，都不会引起调用者睡眠。
• 区别：主要区别在于对中断的处理上。spin_trylock() 不改变当前中断状态，而 spin_trylock_irq() 则会在操作前临时禁用中断，操作后恢复中断状态，确保了操作的原子性。

选择使用哪个函数取决于具体的上下文需求。如果你确信在调用时不希望中断打断锁的获取过程，或者你处于一个可能需要明确控制中断状态的上下文中，spin_trylock_irq() 更为合适。而在不需要特别处理中断，或者明确知道当前中断状态已满足要求的情况下，可以使用 spin_trylock()。