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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 08 Sep 2008 17:17:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	paulmck@...ux.vnet.ibm.com
Cc:	linux-kernel@...r.kernel.org, wli@...omorphy.com,
	sparclinux@...r.kernel.org, manfred@...orfullife.com,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] prevent sparc64 from invoking irq handlers on offline
 CPUs

From: "Paul E. McKenney" <paulmck@...ux.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/