From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
