[lkml]   [2003]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjecta 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.044 / U:11.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site