spinlock(自旋锁)是内核中最常见的锁，它的特点是：等待锁的过程中不休眠，而是占着CPU空转，优点是避免了上下文切换的开销，缺点是该CPU空转属于浪费，spinlock适合用来保护快进快出的临界区。

spinlock有很多限制条件，其中最重要的是，持有spinlock的CPU不能被抢占，持有spinlock的代码不能休眠。如果违反，会发生死锁，后果很严重。持有spinlock的代码不能休眠，这一条是开发者编写内核程序使用spinlock的时候要人工保证的。而持有spinlock的CPU不能被抢占是由spinlock的API本身提供保证，出于效率的考虑，spinlock的API提供了多种选择，对抢占的防止程度也不一样，开发者在选用的时候需要谨慎，下文对此详细展开。

Linux内核提供了多种spinlock的API，其中最常用的是：
spin_lock/spin_unlock — 禁止内核抢占
spin_lock_irq/spin_unlock_irq — 禁止内核抢占并屏蔽中断
spin_lock_irqsave/spin_unlock_irqrestore — 禁止内核抢占并屏蔽中断，事先保存中断屏蔽位并事后恢复原状

spin_lock()禁止了内核抢占，但是没有屏蔽中断，意味着持有该spinlock的CPU有可能被中断抢占。如果你的某段内核代码选用了spin_lock()，就必须保证这段代码不会被任何中断处理程序调用，否则就会发生死锁（参见后文的一个实际发生的案例）。如果某段内核代码有可能被中断处理程序调用，那就只能选择spin_lock_irq或spin_lock_irqsave。

下面是一个刚发生的实际案例，SLES11 SP4的系统失去响应，kdump生成了vmcore，分析过程中发现以下backtraces揭示了原因：

我来解释一下，上面的backtraces意思是：CPU 2上正在运行的进程是”kswapd0″（kswapd0是负责swapping的内核线程），它正在压缩dcache以便腾出一些空闲内存，当它执行到__shrink_dcache_sb()的时候被一个中断抢占了CPU，（注意被中断抢占的进程不会离开当前CPU，不会有机会到其它CPU上运行，只能等中断处理结束之后把CPU交还给它），中断处理程序是bnx2x驱动模块（注意看[]，表示的是内核模块），它发现内存不够，于是自动清理内存，最终也走到了压缩dcache这一步，也去调用__shrink_dcache_sb()，但是__shrink_dcache_sb()的临界区受到spinlock保护，见下面源代码第0823行，这个名为dcache_lru_lock的spinlock刚才已经被”kswapd0″进程持有了，所以中断处理程序不可能抢到，问题是持有dcache_lru_lock的”kswapd0″进程又被中断抢占了CPU，不可能继续运行，也就没机会释放掉dcache_lru_lock，这就陷入了死锁状态。

根本原因在于，既然__shrink_dcache_sb()选用了spin_lock()，就意味着设计者认为它不会被中断处理程序调用，因为spin_lock()不屏蔽中断，是不能防止中断抢占的，只要中断处理程序不调用__shrink_dcache_sb()，死锁就不会发生；如果要让__shrink_dcache_sb()可以被中断处理程序调用，那就不能选用spin_lock()，而应该用spin_lock_irq或spin_lock_irqsave。这个案例中的问题出在bnx2x驱动程序中，它在bnx2x_alloc_rx_sge() 中调用alloc_pages()时不恰当地使用了GFP_KERNEL标志，实际上应该使用GFP_ATOMIC标志，这样alloc_pages()就不会试图去主动回收内存、也就不会最终调用__shrink_dcache_sb()了。此bug记载在SUSE的bsc#975358中，在kernel 3.0.101-77中得以修复。