mm: flush TLB once pages are copied when SPF is on
Vinayak Menon reported that the following scenario results in
threads A and B of process 1 blocking on pthread_mutex_lock
forever after few iterations.
CPU 1 CPU 2 CPU 3
Process 1, Process 1, Process 1,
Thread A Thread B Thread C
while (1) { while (1) { while(1) {
pthread_mutex_lock(l) pthread_mutex_lock(l) fork
pthread_mutex_unlock(l) pthread_mutex_unlock(l) }
} }
When from thread C, copy_one_pte write-protects the parent pte
(of lock l), stale tlb entries can exist with write permissions
on one of the CPUs at least. This can create a problem if one
of the threads A or B hits the write fault. Though dup_mmap calls
flush_tlb_mm after copy_page_range, since speculative page fault
does not take mmap_sem it can proceed further fixing a fault soon
after CPU 3 does ptep_set_wrprotect. But the CPU with stale tlb
entry can still modify old_page even after it is copied to
new_page by wp_page_copy, thus causing a corruption.
Change-Id: Id9cb10d745f96fadec693ffad61c7d999d15bd81
Patch-mainline: linux-mm @ Wed, 16 Jan 2019 14:31:21
Reported-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
[vinmenon@codeaurora.org: fix the addr passed to flush_tlb_range]
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
1 file changed