Re: Spinlocks, intr levels et al

[Kanoj Sarcar]

> >
> > > * 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
> 
> 
>