Thank you so much for kindly explaining the problem! as Wonhyuk Yang and Max Filippov said, I didn't consider the case that interrupt handler holds same lock. there can be deadlock as you said. 2021년 4월 23일 (금) 오후 3:45, Max Filippov <jcmvbkbc@gmail.com>님이 작성:
On Thu, Apr 22, 2021 at 11:28 PM Wonhyuk Yang <vvghjk1234@gmail.com> 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