Re: [PATCH] prevent sparc64 from invoking irq handlers on offline CPUs

[David Miller <davem@davemloft.net>]

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 3 Sep 2008 08:42:17 -0700

> Here are the situations I can think of (no doubt betraying my ignorance
> of modern processor irq hardware in general and of sparc64 in particular):
> 
> o	Pending device irq.  There should be a limited number of these,
> 	and the fixup_irqs() call prevents any more from appearing.

Correct.

> o	Pending scheduling-clock interrupts.  Does fixup_irqs() turn
> 	these off as well?  (It does if the scheduling-clock interrupt
> 	is one of the 0..NR_IRQS irqs.)  On the other hand, leaving
> 	one of these pending should not be a problem (famous last
> 	words).

No, the timer interrupts are controlled differently, as the IRQ source
lives inside of the CPU rather in some external entity.

I need to fix that by invoking tick_ops->disable_irq() here.  I'll take
care of this.

> o	Pending IPIs.  There should again be a limited number of these.
> 	Except that an IPI handler could possibly IPI this CPU, as could
> 	a device irq handler, I suppose.  (We cannot receive additional
> 	IPIs from other CPUs, as they are spinning with irqs disabled.)

And IPI handler runs in HW irq context, therefore such an IPI-creates-an-IPI
should not be allowed, at least not directly.

Actually the restriction seems to be that an IPI cannot be sent when
"irqs_disabled()", hmmm...

> o	Timer irqs.  Not sure what happens to add_timer() calls from
> 	a CPU that is going offline.  The hope would be that they get
> 	queued to some other CPU?

This case is interesting, and I'm no sure what happens here.

> Now, an IPI handler cannot be allowed to send a synchronous IPI to
> anyone, because the other CPUs are spinning with irqs disabled until
> __cpu_disable() returns.  And in any context, a handler for a synchronous
> IPI cannot be allowed to send a synchronous IPI to any set of CPUs that
> might include the sender of the currently running handler, as doing so
> would result in deadlock.

Exactly.