preemptible spinlock?

[Hyeonggon Yoo]

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 at gmail.com>님이 작성:
>
> On Thu, Apr 22, 2021 at 11:28 PM Wonhyuk Yang <vvghjk1234 at 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