当内核空间中的进程持有spin_lock时，由于以下任何一种情况，该进程不能被抢占：
但是，如果进程阻塞、休眠或显式调用schedule()，则该进程可以让出处理器。我的理解正确吗？
当内核空间中的进程持有mutex_lock时，由于上述1、2和3列出的条件，该进程是否可以被抢占。
【问题讨论】：
标签： locking linux-kernel preemption
当前的自旋锁实现使用两种完全独立的机制来确保互斥，一种用于处理处理器间的排斥，另一种用于处理本地处理器线程和中断处理程序。
spin_lock 本身仅用于在两个或多个处理器内核之间提供互斥锁。任何遇到锁定自旋锁的处理器基本上都会卡住，直到另一个处理器释放它。自旋锁在单处理器系统上没有任何作用——除了增加完全死锁的机会——所以通常在内核编译时被删除。
为了提供本地处理器互斥锁，spin_lock() 调用 preempt_disable()（在抢占式调度系统上）以防止任何其他线程在持有锁时运行；类似地，spin_lock_irqsave() 也执行与 local_irq_save() 等效的操作来禁用中断，以防止在本地处理器上运行任何其他内容。
从上面可以明显看出，使用自旋锁可能会破坏整个机器，因此自旋锁应该只在很短的时间内使用，并且你不应该在持有锁时做任何可能导致重新安排的事情。
mutex_lock 的情况完全不同——只有尝试访问锁的线程会受到影响，如果线程遇到锁定的互斥锁，则会发生重新调度。因此，mutex_locks 不能在中断（或其他原子）上下文中使用。
【讨论】：
mutex_lock() 当IRQ handler保证为线程时，可以在IRQ上下文中使用。