svn commit: r267408 - head/sys/arm/arm

[Alan Cox]

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.
>
>