From owner-svn-src-all@FreeBSD.ORG Thu Jun 12 16:31:16 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28B27340; Thu, 12 Jun 2014 16:31:16 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15C802E43; Thu, 12 Jun 2014 16:31:16 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s5CGVFJs033298; Thu, 12 Jun 2014 16:31:15 GMT (envelope-from jmg@svn.freebsd.org) Received: (from jmg@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s5CGVFm4033297; Thu, 12 Jun 2014 16:31:15 GMT (envelope-from jmg@svn.freebsd.org) Message-Id: <201406121631.s5CGVFm4033297@svn.freebsd.org> From: John-Mark Gurney Date: Thu, 12 Jun 2014 16:31:15 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r267408 - head/sys/arm/arm X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:31:16 -0000 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 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.