Messages in this thread |  | | Date | Fri, 7 Feb 2003 17:02:40 -0800 | From | Jun Sun <> | Subject | a race condition in SMP TLB flushing code? |
| |
We were chasing a bug in MIPS/SMP TLB part, and noticed that i386 may have a race condition in the same area.
Here is the scenario how it may happen:
cpu A: call flush_tlb_mm() find out cpu_vm_mask set for cpu B (cpu_mask != 0)
cpu B: inside schedule(), calling switch_mm() clear cpu_vm_mask bit for current mm, trying stop ipi for flushing tlb
cpu A: oops, but it is a little too late. already checked cpu_vm_mask, and send an ipi to cpu B for flushing tlb anyway.
cpu B: get the ipi and (WITHOUT CHECKING cpu_vm_mask again) go ahead doing tlb flushing.
I am not sure if any disastrous result will happen, but apparently an unintended flush has happened. In MIPS such a hole could cause two processes using the same TLB entries which yields all kinds of interesting crashes.
BTW, I am looking at the 2.4.19 kernel. Please cc your reply to my email address. Thanks.
Jun - 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/
|  |