Messages in this thread | | | From | (Kanoj Sarcar) | Subject | Re: Spinlocks, intr levels et al | Date | Wed, 5 Jan 2000 13:27:26 -0800 (PST) |
| |
> > Kanoj Sarcar wrote: > > > > I have read Documentation/spinlocks.txt. > > > > My problem is this: I have a lock L that is acquired from intr level, > > as well as from process context. Hence, L is grabbed/released with > > spin_lock_irqsave/spin_unlock_irqrestore. While L is held from process > > context, it is possible that the code needs to do an intercpu action > > (eg flush_tlb_all). > > I think you cannot do any intercpu action with disabled interrupts: what > if both cpu's try to perform a different intercpu action?
Yes, your following examples are examples of wrong code, but they do not involve locks. My current problem is that spin_lock_irqsave, instead of atomically raising irq and grabbing lock, has been degraded into two operations, ie, 1. raise irq, 2. grab lock, leading to the same problem as in your examples.
> > IIRC I found 3 places that send ipi's with disabled interrupts: > > * mtrr: it's easy to fix that, just move the "set_mtrr_prepare()" behind > the smp_call_function(). > > * panic(), machine_restart(): both functions call smp_send_stop(), and > this function uses smp_call_function to issue an ipi. > I don't know how to fix this problem, therefore I didn't post a patch. > > > > The only solution I can think of is to have a > > new routine spin_lock_irqsave_intercpu() that raises intr level, > > tries to get the lock, on failure drops the intr level, and retries. > > > > This is only reliable if there is only _one_ such spinlock. As soon as > you have 2 users, you have a lock-up. >
I can not follow your scenario, please give an example, involving cpu1, cpu2 etc, L1, L2 etc. Here is what the proposed spin_lock_irqsave_intercpu() function looks like in theory:
extern inline void spin_lock_irqsave_intercpu(lock, flags) { loop: local_irq_save(flags); if (!spin_trylock(lock)) { local_irq_restore(flags); goto loop; } }
Kanoj
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |