板友们晚安
我想请教一个Linux Kernel的问题，但看了Linux板，感觉不是在讨论code。
所以我就来这里发文看看。若我在这边发文不适合可以在下面回文，我会
再删除，谢谢。
我在【知乎】这个平台看到有关于spin_lock_irq()的介绍
https://reurl.cc/eWe4lb
里面有个图关于spin_lock_irq(&lock1)后再一次spin_lock_irq(&lock2)
紧接着spin_unlock_irq(&lock2)后，CPU发生了interrupt，若好死不死
这ISR内要执行lock1所保护的critical section，由于前面已有task获取
到lock1的锁了，ISR内铁定拿不到lock1便会deadlock.
其实我不太知道为何deadlock的原因。查了网络上的说明更加混乱了...
这有两种deadlock的原因请问是哪一种呢?
1.ISR内因获得不到锁所以永久的spin，所以先前拿到锁的task也因此无法解锁.
2.先前拿到锁的task在被中断后状态变成TASK_INTERRUPT，schedual无法再调度
task使之有机会解锁,这意味着ISR内不会永久spin，且有一定的时间霸占CPU?
希望能有kernel高手能解答小弟疑惑@@，谢谢。

ISR lock要等被interrupt的task unlock->可是cpu不会切永远等不到task unlock-> deadlock

有LinuxDev版。

原因如楼上，另外这主要是说明 spin_lock_irqsave 的需求因 lock_irq 没有处理 nested，导致 unlock_irq(&lock2)时就立即 enable IRQ，因此进入 deadlock 状态。修正上述: 有机会进入 deadlock 状态改用 lock_irqsave 后才能在 unlock 时回复先前 IRQ 状态而非无脑启用 IRQ。进而解决了误启用 IRQ 导致的 deadlock

请问原因是我列的第一种情况吗? ^^" 再确认一下

你这句“schedual无法再调度task使之有机会解锁”是啥意思？没法被排程的话，给定task怎么解开原先获得的锁？

我的意思是想说第2, ISR不会霸占CPU, OS透过schedual让其他task使用CPU，只是不会给有lock的task。因为也是从网络上看的，我也不知道是不是第2点而造成deadlock

ISR 霸占 CPU 的理由是，interrupt 会设定较高的优先权优先处理，但 ISR 又卡死在抢占 lock 的工作时间到了 timer interrupt 跳起来，CPU 进到 schedulerscheduler 会选定优先权高的程序，也就是 ISR 继续执行

因为查了资料，ISR并不是process，也就不会被schedualhttps://reurl.cc/QW1lpb

这样说有道理，应该说 ISR 是中断处理，除非有权限更高的interrupt，否则它不会被 timer interrupt 打断所以一但 ISR 在等待某个资源解锁，CPU 就直接卡死在那里