From owner-cvs-src@FreeBSD.ORG Tue Feb 15 23:54:03 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A72016A4CE; Tue, 15 Feb 2005 23:54:03 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21EB243D58; Tue, 15 Feb 2005 23:54:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 1E9BA7A41E; Tue, 15 Feb 2005 15:37:50 -0800 (PST) Message-ID: <421287CD.1080106@elischer.org> Date: Tue, 15 Feb 2005 15:37:49 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein References: <200502152217.j1FMH7Qf054657@repoman.freebsd.org> <20050215224018.GJ32955@elvis.mu.org> In-Reply-To: <20050215224018.GJ32955@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Bosko Milekic cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm memguard.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 23:54:03 -0000 Alfred Perlstein wrote: >Where can I read more about this feature? :) > You have to nail Boscoe to a sheet of 1m x 2m plywood and subject him to crude borg mind reading techniques. The upside is that if you succeed we get to do the same to you to find out what you learned. :-) > >* 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 >> >> > > >