svn commit: r336491 - head/sys/vm

[Alan Cox]

Author: alc
Date: Thu Jul 19 17:01:10 2018
New Revision: 336491
URL: https://svnweb.freebsd.org/changeset/base/336491

Log:
  Revert r329254.  The underlying cause for the copy-on-write problem in
  multithreaded programs that was addressed by r329254 was in the
  implementation of pmap_enter() on some architectures, notably, amd64.
  kib@, markj@ and I have audited all of the pmap_enter() implementations,
  and fixed the broken ones, specifically, amd64 (r335784, r335971), i386
  (r336092), mips (r336248), and riscv (r336294).
  
  To be clear, the reason to address the problem within pmap_enter() and
  revert r329254 is not just a matter of principle.  An effect of r329254
  was that a copy-on-write fault actually entailed two page faults, not
  one, even for single-threaded programs.  Now, in the expected case for
  either single- or multithreaded programs, we are back to a single page
  fault to complete a copy-on-write operation.  (In extremely rare
  circumstances, a multithreaded program could suffer two page faults.)
  
  Reviewed by:	kib, markj
  Tested by:	truckman
  MFC after:	3 weeks
  Differential Revision:	https://reviews.freebsd.org/D16301

Modified:
  head/sys/vm/vm_fault.c

Modified: head/sys/vm/vm_fault.c
==============================================================================
--- head/sys/vm/vm_fault.c	Thu Jul 19 16:58:20 2018	(r336490)
+++ head/sys/vm/vm_fault.c	Thu Jul 19 17:01:10 2018	(r336491)
@@ -1152,10 +1152,6 @@ readrest:
 				 */
 				pmap_copy_page(fs.m, fs.first_m);
 				fs.first_m->valid = VM_PAGE_BITS_ALL;
-				if ((fault_flags & VM_FAULT_WIRE) == 0) {
-					prot &= ~VM_PROT_WRITE;
-					fault_type &= ~VM_PROT_WRITE;
-				}
 				if (wired && (fault_flags &
 				    VM_FAULT_WIRE) == 0) {
 					vm_page_lock(fs.first_m);