Re: i386 IPI handlers running with hardirq_count == 0

[Andrew Morton <akpm@osdl.org>]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * 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.
> 

There's a risk that spin_unlock() in an IPI handler could blow up due to it
trying to reschedule.  But preempt_schedule() explicitly checks the CPU's
interupt flag so as long as that doesn't change we're OK.