From owner-cvs-all@FreeBSD.ORG Tue Feb 15 22:40:18 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A14F16A4CE; Tue, 15 Feb 2005 22:40:18 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43BE343D48; Tue, 15 Feb 2005 22:40:18 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 39B405C992; Tue, 15 Feb 2005 14:40:18 -0800 (PST) Date: Tue, 15 Feb 2005 14:40:18 -0800 From: Alfred Perlstein To: Bosko Milekic Message-ID: <20050215224018.GJ32955@elvis.mu.org> References: <200502152217.j1FMH7Qf054657@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502152217.j1FMH7Qf054657@repoman.freebsd.org> User-Agent: Mutt/1.4.2.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm memguard.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 22:40:18 -0000 Where can I read more about this feature? :) * Bosko Milekic [050215 14:17] wrote: > bmilekic 2005-02-15 22:17:07 UTC > > FreeBSD src repository > > Modified files: > sys/vm memguard.c > Log: > Rather than overloading the page->object field like UMA does, use instead > an unused pageq queue reference in the page structure to stash a pointer > to the MemGuard FIFO. Using the page->object field caused problems > because when vm_map_protect() was called the second time to set > VM_PROT_DEFAULT back onto a set of pages in memguard_map, the protection > in the VM would be changed but the PMAP code would lazily not restore > the PG_RW bit on the underlying pages right away (see pmap_protect()). > So when a page fault finally occured and the VM noticed the faulting > address corresponds to a page that _does_ have write access now, it > would then call into PMAP to set back PG_RW (i386 case being discussed > here). However, before it got to do that, an assertion on the object > lock not being owned would get triggered, as the object of the faulting > page would need to be locked but was overloaded by MemGuard. This is > precisely why MemGuard cannot overload page->object. > > Submitted by: Alan Cox (alc@) > > Revision Changes Path > 1.4 +13 -17 src/sys/vm/memguard.c -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684