Messages in this thread |  | | | From | (Kanoj Sarcar) | | Subject | Re: Spinlocks, intr levels et al | | Date | Thu, 6 Jan 2000 12:17:38 -0800 (PST) |
| |
> > Kanoj Sarcar wrote: > > Okay. Btw, thinking about this more, spin_lock_irqsave_intercpu() > > might be problematic even for a single lock L1. Assume cpu1 has > > the lock L1, then cpu2 gets an intr, also tries doing > > spin_lock_irqsave_intercpu(&L1). cpu1 now tries to do an inter > > cpu function, but cpu2 will not be able to reply. Unless the > > inter cpu function uses a suitably higher irq level to interrupt > > other cpus. > > > > Right? >
Okay, I was able to get around my original problem: basically, I think it is quite complex to do intercpu interrupts while holding a lock that can also be acquired from intr level. So, I recoded a little bit to get the ipi's done without holding the lock.
In case anyone is interested, I can now do kunmap()'s from intr context, without deadlocking with ipi's needed for flush_tlb_all().
> Yes. I think that ipi's with disabled interrupts lead to madness. Just > check the tlb flush code: in order to handle crossing invalidates, > wait_on_irq() must poll the smp_invalidate_needed bitmap...
I am willing to tolerate this, since all the complexity is hidden inside the flush_tlb* primitives. If the i386 specific version will hold intrs high while one flush_tlb* is happening, I am willing to let it handle the complexity of multiple, concurrent flush_tlb*s by polling bitmaps etc.
> > Btw, I would propose a change of change the prototype for > smp_call_function(): > > currently: > int smp_call_function(fnc, info, wait, retry) > > wait: wait until the ipi functions on all other cores have finished > retry: schedule() until the required data structures are free > > returns -EBUSY on error (IIRC) > > new: > void smp_call_function(fnc,info,wait) >
I am assuming you mean go from
int smp_call_function (void (*func) (void *info), void *info, int nonatomic, int wait)
to
void smp_call_function (void (*func) (void *info), void *info, int wait)
> * never fails. panic() [on i386] indirectly relies on > smp_call_function(), and panic() shouldn't fail ;) > * never schedules, it uses a normal spinlock. [panic() could > schedule...]
Yes, the above two are real problems. OTOH, have you walked the code path down under panic() to identify all the scheduling points? Seems to me sys_sync is another such point, maybe we should not be doing that too?
Using a spinlock instead of a sleeping lock inside smp_call_function() is a good idea.
> * the call-back is called with disalbed interrupts, and it must not > reenable interrupts. [docu clarification]
Shouldn't this already be happening?
> * smp_call_function() itself enables interrupts, otherwise we could lock > up.[the current code call schedule(), and thus indirectly reenables the > interrupts]
Umm, I don't quite see the point. Are you sure smp_call_function() is never called from intr context today? Even if not today, it would be nice to let this happen in the future. I see the possibility of deadlock with this though (the sleeping lock in smp_call_function() currently prevents this I think). To prevent the deadlock, I think smp_call_function() would need to have a percpu bitmask of possible ipi's that it needs to check while it can not acquire the new spinlock that will replace ther sleeping lock.
Or am I just confused?
Kanoj
> > The "only" problem is that smp_call_function() is a documented > cross-platform function, ie I doubt that Linus would accept the patch, > but OTHO the current code it horribly broken. > > What do you think? > -- > Manfred >
- 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/
|  |