Date: Tue, 15 Feb 2005 14:40:18 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Bosko Milekic <bmilekic@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm memguard.c Message-ID: <20050215224018.GJ32955@elvis.mu.org> In-Reply-To: <200502152217.j1FMH7Qf054657@repoman.freebsd.org> References: <200502152217.j1FMH7Qf054657@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Where can I read more about this feature? :) * Bosko Milekic <bmilekic@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050215224018.GJ32955>