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/
