Re: preemptible spinlock?

[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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies