From owner-svn-src-stable-8@FreeBSD.ORG Tue Jul 29 13:08:56 2014 Return-Path: Delivered-To: svn-src-stable-8@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 B19D3568; Tue, 29 Jul 2014 13:08:56 +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 8228A2C98; Tue, 29 Jul 2014 13:08:56 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id s6TD8umv067037; Tue, 29 Jul 2014 13:08:56 GMT (envelope-from marius@svn.freebsd.org) Received: (from marius@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id s6TD8uFM067036; Tue, 29 Jul 2014 13:08:56 GMT (envelope-from marius@svn.freebsd.org) Message-Id: <201407291308.s6TD8uFM067036@svn.freebsd.org> From: Marius Strobl Date: Tue, 29 Jul 2014 13:08:56 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-8@freebsd.org Subject: svn commit: r269237 - stable/8/sys/i386/i386 X-SVN-Group: stable-8 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable-8@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for only the 8-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:08:56 -0000 Author: marius Date: Tue Jul 29 13:08:56 2014 New Revision: 269237 URL: http://svnweb.freebsd.org/changeset/base/269237 Log: MFC: r269050 (partial) Copying and zeroing pages via temporary mappings involves updating the corresponding page tables followed by accesses to the pages in question. This sequence is subject to the situation exactly described in the "AMD64 Architecture Programmer's Manual Volume 2: System Programming" rev. 3.23, "7.3.1 Special Coherency Considerations" [1, p. 171 f.]. Therefore, issuing the INVLPG right after modifying the PTE bits is crucial. For pmap_copy_page(), this has been broken in r124956. 1: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/24593_APM_v21.pdf Reviewed by: alc, kib Sponsored by: Bally Wulff Games & Entertainment GmbH Modified: stable/8/sys/i386/i386/pmap.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/i386/ (props changed) Modified: stable/8/sys/i386/i386/pmap.c ============================================================================== --- stable/8/sys/i386/i386/pmap.c Tue Jul 29 13:08:46 2014 (r269236) +++ stable/8/sys/i386/i386/pmap.c Tue Jul 29 13:08:56 2014 (r269237) @@ -1263,6 +1263,13 @@ pmap_pte_release(pt_entry_t *pte) mtx_unlock(&PMAP2mutex); } +/* + * NB: The sequence of updating a page table followed by accesses to the + * corresponding pages is subject to the situation described in the "AMD64 + * Architecture Programmer's Manual Volume 2: System Programming" rev. 3.23, + * "7.3.1 Special Coherency Considerations". Therefore, issuing the INVLPG + * right after modifying the PTE bits is crucial. + */ static __inline void invlcaddr(void *caddr) { @@ -4096,12 +4103,12 @@ pmap_copy_page(vm_page_t src, vm_page_t if (*sysmaps->CMAP2) panic("pmap_copy_page: CMAP2 busy"); sched_pin(); - invlpg((u_int)sysmaps->CADDR1); - invlpg((u_int)sysmaps->CADDR2); *sysmaps->CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A | pmap_cache_bits(src->md.pat_mode, 0); + invlcaddr(sysmaps->CADDR1); *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(dst) | PG_A | PG_M | pmap_cache_bits(dst->md.pat_mode, 0); + invlcaddr(sysmaps->CADDR2); bcopy(sysmaps->CADDR1, sysmaps->CADDR2, PAGE_SIZE); *sysmaps->CMAP1 = 0; *sysmaps->CMAP2 = 0;