svn commit: r280238 - head/sys/vm

[Konstantin Belousov]

On Thu, Mar 19, 2015 at 01:40:44AM +0000, Alan Cox wrote:
> 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

Note that r267213 is already in stable/10, see r269072.  It was needed
for the rewrite of the resident page count reporting for kern.proc.vmmap.