preemptible spinlock?

preemptible spinlock?

[유형곤]

I'm learning how spinlock works.

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.

is enabling preemption in such spinlock a bad idea?

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

RE: preemptible spinlock?

[Wonhyuk Yang]

[-- Attachment #1.1: Type: text/plain, Size: 619 bytes --]

Hi,

> 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.

[-- Attachment #1.2: Type: text/html, Size: 1160 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

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

Re: preemptible spinlock?

[Max Filippov]

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

Re: 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@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