lkml.org 
[lkml]   [2003]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH] Readd BUG for SMP TLB IPI

Readd the BUG for an spurious SMP TLB IPI.

Rationale:

The condition is fatal and it's better to have a BUG than a hang.
The goto out code forgets to ack the IPI in the APIC. When the IPI would really arrive
at the wrong CPU it would immediately deadlock because the non-Acked IPI is retriggered.
Adding an ACK for this path is also no good, because then the SMP flusher would
need to detect this case and "retransmit" the IPI, otherwise it would hang too
in the loop waiting for other CPUs. But nobody has ever seen such a hang, so it's safe
to assume that all hardware guarantees it cannot happen.

-Andi

--- linux-2.5-amd64/arch/i386/kernel/smp.c~ 2003-07-09 12:42:36.000000000 +0200
+++ linux-2.5-amd64/arch/i386/kernel/smp.c 2003-07-09 12:42:36.000000000 +0200
@@ -312,15 +312,7 @@
cpu = get_cpu();

if (!test_bit(cpu, &flush_cpumask))
- goto out;
- /*
- * This was a BUG() but until someone can quote me the
- * line from the intel manual that guarantees an IPI to
- * multiple CPUs is retried _only_ on the erroring CPUs
- * its staying as a return
- *
- * BUG();
- */
+ BUG();

if (flush_mm == cpu_tlbstate[cpu].active_mm) {
if (cpu_tlbstate[cpu].state == TLBSTATE_OK) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.056 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site