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?
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...
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)
* 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...]
* the call-back is called with disalbed interrupts, and it must not
reenable interrupts. [docu clarification]
* smp_call_function() itself enables interrupts, otherwise we could lock
up.[the current code call schedule(), and thus indirectly reenables the
interrupts]
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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST