[lkml]   [2008]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] prevent sparc64 from invoking irq handlers on offline CPUs
From: "Paul E. McKenney" <>
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.


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


 \ /
  Last update: 2008-09-09 02:19    [W:0.052 / U:1.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site