svn commit: r267408 - head/sys/arm/arm
Alan Cox
alc at rice.edu
Thu Jun 12 16:47:02 UTC 2014
On 06/12/2014 11:31, John-Mark Gurney wrote:
> Author: jmg
> Date: Thu Jun 12 16:31:15 2014
> New Revision: 267408
> URL: http://svnweb.freebsd.org/changeset/base/267408
>
> Log:
> clear the write bit... This allows my AVILA board to survive a
> 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
Yes, 10.x definitely needs this change. I'm less certain about 9.x, but
it's not going to break anything if you do commit it to 9.x.
> Modified:
> head/sys/arm/arm/pmap.c
>
> Modified: head/sys/arm/arm/pmap.c
> ==============================================================================
> --- head/sys/arm/arm/pmap.c Thu Jun 12 16:26:26 2014 (r267407)
> +++ head/sys/arm/arm/pmap.c Thu Jun 12 16:31:15 2014 (r267408)
> @@ -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.
>
>
More information about the svn-src-all
mailing list