summaryrefslogtreecommitdiffstats
path: root/sbin/sunlabel
diff options
context:
space:
mode:
authorbmilekic <bmilekic@FreeBSD.org>2005-02-15 22:17:07 +0000
committerbmilekic <bmilekic@FreeBSD.org>2005-02-15 22:17:07 +0000
commit04e8cef9b4d31f7aa83936f7554e8a757394d805 (patch)
treec62390077b3556e5b8c21300f51bcbbc2b00ada8 /sbin/sunlabel
parent0054992ccdf09c6d1e4596265a1fcf6de80db953 (diff)
downloadFreeBSD-src-04e8cef9b4d31f7aa83936f7554e8a757394d805.zip
FreeBSD-src-04e8cef9b4d31f7aa83936f7554e8a757394d805.tar.gz
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@)
Diffstat (limited to 'sbin/sunlabel')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud