On Wed, Nov 09, 2005 at 18:38:11 +0000, Bahadir Balban wrote: > On 11/9/05, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote: > 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 have to use the _*save/_*restore variants (or disable/enable ones if you are sure about the current state) if the resource is shared with IRQ/BH. > 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. I don't know about runqueue balancing, at least not by that name, but a few comments anyway: > 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. It did disable BHs, because the BH can run on any CPU. It depends on which CPU first reaches point suitable for running the BH. I am not sure whether it depends on which CPU the interrupt was handled on, but that can still be any of them. > 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? I think I understand now. Process can only ever move from one CPU to another when it's sleeping (or more precisly, when it's being taken out of the runqueue during a scheduling pass). And a process holding spinlock can't be put to sleep. So it can't be moved to another CPU. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
