d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

clear the write bit... This allows my AVILA board to survive a

Browse Source 
portsnap extract, where previously it would panic..  clearly someone
who knows pmap should optimize this code per alc's comment...

Submitted by:	alc
MFC after:	probably
This commit is contained in:
John-Mark Gurney 2014-06-12 16:31:15 +00:00
parent d1aefcd58f
commit 4f4bd09dd1
1 changed files with 9 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
sys/arm/arm/pmap.c
View File

@ -3034,7 +3034,14 @@ pmap_remove_all(vm_page_t m)
if (TAILQ_EMPTY(&m->md.pv_list))
return;
rw_wlock(&pvh_global_lock);
pmap_remove_write(m);
/*
* XXX This call shouldn't exist. Iterating over the PV list twice,
* once in pmap_clearbit() and again below, is both unnecessary and
* inefficient. The below code should itself write back the cache
* entry before it destroys the mapping.
*/
pmap_clearbit(m, PVF_WRITE);
curpm = vmspace_pmap(curproc->p_vmspace);
while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) {
if (flush == FALSE && (pv->pv_pmap == curpm ||
@ -3043,7 +3050,7 @@ pmap_remove_all(vm_page_t m)
PMAP_LOCK(pv->pv_pmap);
/*
* Cached contents were written-back in pmap_remove_write(),
* Cached contents were written-back in pmap_clearbit(),
* but we still have to invalidate the cache entry to make
* sure stale data are not retrieved when another page will be
* mapped under this virtual address.