Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Mar 2015 01:40:44 +0000 (UTC)
From:      Alan Cox <alc@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r280238 - head/sys/vm
Message-ID:  <201503190140.t2J1ei0s021349@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: alc
Date: Thu Mar 19 01:40:43 2015
New Revision: 280238
URL: https://svnweb.freebsd.org/changeset/base/280238

Log:
  Fix the root cause of the "vm_reserv_populate: reserv <address> is already
  promoted" panics.  The sequence of events that leads to a panic is rather
  long and circuitous.  First, suppose that process P has a promoted
  superpage S within vm object O that it can write to.  Then, suppose that P
  forks, which leads to S being write protected.  Now, before P's child
  exits, suppose that P writes to another virtual page within O.  Since the
  pages within O are copy on write, a shadow object for O is created to
  house the new physical copy of the faulted on virtual page.  Then, before
  P can fault on S, P's child exists.  Now, when P faults on S, it will
  follow the "optimized" path for copy-on-write faults in vm_fault(),
  wherein the underlying physical page is moved from O to its shadow object
  rather than allocating a new page and copying the new page's contents from
  the old page.  Moreover, suppose that every 4 KB physical page making up S
  is moved to the shadow object in this way.  However, the optimized path
  does not move the underlying superpage reservation, which is the root
  cause of the panics!  Ultimately, P performs vm_object_collapse() on O's
  shadow object, which destroys O and in doing so breaks any reservations
  still belonging to O.  This leaves the reservation underlying S in an
  inconsistent state: It's simultaneously not in use and promoted.  Breaking
  a reservation does not demote it because I never intended for a promoted
  reservation to be broken.  It makes little sense.  Finally, this
  inconsistency leads to an assertion failure the next time that the
  reservation is used.
  
  The failing assertion does not (currently) exist in FreeBSD 10.x or
  earlier.  There, we will quietly break the promoted reservation.  While
  illogical and unintended, breaking the reservation is essentially
  harmless.
  
  PR:		198163
  Reviewed by:	kib
  Tested by:	pho
  X-MFC after:	r267213
  Sponsored by:	EMC / Isilon Storage Division

Modified:
  head/sys/vm/vm_fault.c

Modified: head/sys/vm/vm_fault.c
==============================================================================
--- head/sys/vm/vm_fault.c	Thu Mar 19 00:23:16 2015	(r280237)
+++ head/sys/vm/vm_fault.c	Thu Mar 19 01:40:43 2015	(r280238)
@@ -101,6 +101,7 @@ __FBSDID("$FreeBSD$");
 #include <vm/vm_kern.h>
 #include <vm/vm_pager.h>
 #include <vm/vm_extern.h>
+#include <vm/vm_reserv.h>
 
 #define PFBAK 4
 #define PFFOR 4
@@ -858,6 +859,14 @@ vnode_locked:
 					unlock_and_deallocate(&fs);
 					goto RetryFault;
 				}
+#if VM_NRESERVLEVEL > 0
+				/*
+				 * Rename the reservation.
+				 */
+				vm_reserv_rename(fs.m, fs.first_object,
+				    fs.object, OFF_TO_IDX(
+				    fs.first_object->backing_object_offset));
+#endif
 				vm_page_xbusy(fs.m);
 				fs.first_m = fs.m;
 				fs.m = NULL;



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201503190140.t2J1ei0s021349>