From owner-svn-src-all@FreeBSD.ORG Thu Mar 19 10:15:55 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD3BB215; Thu, 19 Mar 2015 10:15:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7ED38966; Thu, 19 Mar 2015 10:15:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2JAFm2Q064270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2015 12:15:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2JAFm2Q064270 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2JAFmVv064269; Thu, 19 Mar 2015 12:15:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Mar 2015 12:15:48 +0200 From: Konstantin Belousov To: Alan Cox Subject: Re: svn commit: r280238 - head/sys/vm Message-ID: <20150319101548.GA2379@kib.kiev.ua> References: <201503190140.t2J1ei0s021349@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201503190140.t2J1ei0s021349@svn.freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 10:15:55 -0000 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
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.