Date: Thu, 19 Mar 2015 12:15:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Cox <alc@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r280238 - head/sys/vm Message-ID: <20150319101548.GA2379@kib.kiev.ua> In-Reply-To: <201503190140.t2J1ei0s021349@svn.freebsd.org> References: <201503190140.t2J1ei0s021349@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150319101548.GA2379>