Re: spinlocks and preemption

[Fawad Lateef <fawadlateef@xxxxxxxxx>]

On 11/9/05, Bahadir Balban <bilgehan.balban@xxxxxxxxx> wrote:
> On 11/9/05, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote:
> > > 3) No matter what context you're in, *if, and only if* your spinlock
> > > is shared with BH and/or Irq contexts, you disable them on the current
> > > CPU, for they may interrupt yours, and deadlock on your spinlock.
> > >
> >
> > I won't able to get what you want to say/ask ?
>
> Thanks for the reply. I tried to make it a summary, sorry if its
> unclear. I actually meant, the *resource* is shared with BH and/or IRQ
> contexts.
>
> 3) So in verbose words, no matter whether you're in process, interrupt
> or bottom half context, iff your resource is shared with a BH and/or
> IRQ context, you disable that context on the current CPU when
> acquiring the spinlock. Because they may interrupt yours, attempt to
> lock your resource and deadlock.
>

Yes, you are right !  like moslty spin_lock_irqsave is used to disable
interrupts (interrupt context to occur)

> To clarify this; for (4) I meant a CPU with a context that holds a
> spinlock would never be involved in a runqueue balancing with other
> CPUs, to avoid possible deadlocks.
>
> To open this, a scenario I made up:
> Process (A) holds a spinlock on CPU A, to protect against a BH (B) on
> CPU B. Because the BH (B) is on CPU B, Process (A) hasn't disabled
> bottom halves when acquiring the lock, as there's no point doing so.
> Furthermore while holding the spinlock, imagine a runqueue balancing
> happens and it is migrated to CPU B. Then is there a danger that
> bottom half (B) takes over, attempts on the spinlock and deadlocks CPU
> B?
>

Sorry, I can't comment on this as don't know about runqueue-balancing
(or might know about it but not with the name "runqueue-balancing")

--
Fawad Lateef

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/