Messages in this thread Patch in this message | | | Date | Wed, 9 Jul 2003 12:49:15 +0200 | From | Andi Kleen <> | 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/
| |