On Thu, Apr 22, 2021 at 11:28 PM Wonhyuk Yang <vvghjk1234@xxxxxxxxx> wrote: > > I think the main idea spinlock disables preemption is, > > > the other process that's spinning on the lock can acquire lock. > > > but in some implementations of spinlock, like qspinlock in x86 (or mcs lock), > > I think there's no need to disable preemption. because processes > > waiting for lock cannot acquire the lock before the lock holder hand > > over to other process. > > Are you talking about disabling local irq(ex. spin_lock_irqsave)? > > If so, think about the situation that a process holding the lock is preempted > by interrupt. And that interrupt handler tries to grab the spinlock. > It will lead to deadlock. Usually the word "preemption" is used when a task switch occurs and one task preempts another task. Interrupts and tasklets are not usually described with this word. Now if an interrupt handler may need to acquire a lock that may also be acquired by a task then the task must use spin_lock_irq or spin_lock_irqsave to avoid the possibility of a deadlock. This is documented in Documentation/kernel-hacking/locking.rst Going back to the original question: > > but in some implementations of spinlock, like qspinlock in x86 (or mcs lock), > > I think there's no need to disable preemption. because processes > > waiting for lock cannot acquire the lock before the lock holder hand > > over to other process. Imagine what happens if a task acquires a spinlock, gets interrupted, task switch happens in the interrupt (remember, preemption is enabled), and the new task tries to acquire the same spinlock on the same CPU? -- Thanks. -- Max _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
