Re: i386 IPI handlers running with hardirq_count == 0

[Ingo Molnar <mingo@elte.hu>]

* Keith Owens <kaos@ocs.com.au> wrote:

> My question has nothing to do with NMI.  I am querying inconsistent 
> behaviour amongst normal IPIs, this list :-
> 
> i386 function                   irq_enter?
> smp_apic_timer_interrupt           yes
> smp_call_function_interrupt        yes
> smp_error_interrupt                yes
> smp_invalidate_interrupt           no - why
> smp_reschedule_interrupt           no (does not need it)
> smp_spurious_interrupt             yes
> smp_thermal_interrupt              yes
> 
> x86_64 function                 irq_enter?
> mce_threshold_interrupt            yes
> smp_apic_timer_interrupt           yes
> smp_call_function_interrupt        yes
> smp_error_interrupt                yes
> smp_invalidate_interrupt           no - why
> smp_reschedule_interrupt           no (does not need it)
> smp_spurious_interrupt             yes
> smp_thermal_interrupt              yes

irq_enter() is mostly just for the purpose of in_interrupt()/in_irq() to 
work as expected, not much else. [also the timer code assumes that 
update_process_times() is called in a HARDIRQ_OFFSET elevated context, 
so the apic timer IRQ needs irq_enter() too.] The 
smp_invalidate_interrupt() and smp_reschedule_interrupt() is 
performance-critical and they dont need irq_enter()/irq_exit().

Since smp_call_function_interrupt() can be called with driver-supplied 
function vectors, it's best to keep the irq_enter()/exit there. [for 
example mm/slab.c has some in_interrupt() sanity checks.] Obviously 
do_IRQ() itself needs irq_enter()/exit() too - plus the APIC timer irq 
as mentioned above.
 
Otherwise, the rest of the SMP functions technically dont need 
irq_enter()/irq_exit(). [i.e. threshold, error, spurious and thermal] We 
could remove it from them.

	Ingo