> >
> > > * 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 really don't know. If you send an ipi with disabled interrupts, you are
> inches away from a lock-up.
>
> Remember that if cpu0 runs with disabled interrupts, it has a reason to do
> so: usually, it owns an interrupt spinlock. But this means that cpu1 could
As I mentioned, owning an interrupt spinlock and doing an ipi is currently
bound to deadlock.
That does not mean we should cramp smp_call_function() and make it not
callable from an intr context though. I can't imagine why, but in theory
it should be possible to do smp_call_function() from inside an intr context
without holding an interrupt spinlock.
Of course, if two cpus are doing this to each other, this will again
deadlock, that is why I also mentioned that there needs to be percpu
bitmasks that each cpu will check inside of smp_call_function() (as
is done with smp_invalidate_needed).
Kanoj
> be spinning for that spinlock [with disabled local interrupts]--> lock-up.
>
> I'll write a patch and wait for an answer from Linus.
>
> --
> 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:07 EST