转自：http://blog.csdn.net/wh_19910525/article/details/11536279
在Linux内核中何时使用spin_lock，何时使用spin_lock_irqsave很容易混淆。首先看一下代码是如何实现的。
spin_lock的调用关系
- spin_lock -----> raw_spin_lock
1 static inline void __raw_spin_lock(raw_spinlock_t *lock)
2 {
3 preempt_disable();
4 spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
5 LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
6 }
- spin_lock_irq的调用关系
spin_lock_irq------> raw_spin_lock_irq
1 static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
2 {
3 local_irq_disable();
4 preempt_disable();
5 spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
6 LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
7 }
1. 可以看出来他们两者只有一个差别：是否调用local_irq_disable()函数， 即是否禁止本地中断。
2. 在任何情况下使用spin_lock_irq都是安全的。因为它既禁止本地中断，又禁止内核抢占。
3. spin_lock比spin_lock_irq速度快，但是它并不是任何情况下都是安全的。
1. spin_lock/spin_unlock:
进程A中调用了spin_lock（&lock）然后进入临界区，此时来了一个中断(interrupt），该中断也运行在和进程A相同的CPU上，并且在该中断处理程序中恰巧也会spin_lock(&lock)， 试图获取同一个锁。由于是在同一个CPU上被中断，进程A会被设置为TASK_INTERRUPT状态，中断处理程序无法获得锁，会不停的忙等，由于进程A被设置为中断状态，schedule()进程调度就无法再调度进程A运行，这样就导致了死锁！
但是如果该中断处理程序运行在不同的CPU上就不会触发死锁。 因为在不同的CPU上出现中断不会导致进程A的状态被设为TASK_INTERRUPT，只是换出。当中断处理程序忙等被换出后，进程A还是有机会获得CPU，执行并退出临界区。所以在使用spin_lock时要明确知道该锁不会在中断处理程序中使用。
2. spin_lock_irqsave/spin_unlock_irqrestore
使用spin_lock_irqsave在于你不期望在离开临界区后，改变中断的开启/关闭状态！进入临界区是关闭的，离开后它同样应该是关闭的！
如果自旋锁在中断处理函数中被用到，那么在获取该锁之前需要关闭本地中断，spin_lock_irqsave 只是下列动作的一个便利接口：
1 保存本地中断状态(这里的本地即当前的cpu的所有中断)
2 关闭本地中断
3 获取自旋锁
解锁时通过 spin_unlock_irqrestore完成释放锁、恢复本地中断到之前的状态等工作
3. spin_lock_irq/spin_unlock_irq
spin_lock_irq----->raw_spin_lock_irq
spin_lock_irq 和 spin_unlock_irq, 如果你确定在获取锁之前本地中断是开启的，那么就不需要保存中断状态，解锁的时候直接将本地中断启用就可以啦