From owner-p4-projects@FreeBSD.ORG Mon Sep 8 16:04:06 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 40860106566C; Mon, 8 Sep 2008 16:04:06 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0466E106564A for ; Mon, 8 Sep 2008 16:04:06 +0000 (UTC) (envelope-from raj@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id EAE158FC18 for ; Mon, 8 Sep 2008 16:04:05 +0000 (UTC) (envelope-from raj@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id m88G45D1066350 for ; Mon, 8 Sep 2008 16:04:05 GMT (envelope-from raj@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id m88G45u1066348 for perforce@freebsd.org; Mon, 8 Sep 2008 16:04:05 GMT (envelope-from raj@freebsd.org) Date: Mon, 8 Sep 2008 16:04:05 GMT Message-Id: <200809081604.m88G45u1066348@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to raj@freebsd.org using -f From: Rafal Jaworowski To: Perforce Change Reviews Cc: Subject: PERFORCE change 149427 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 16:04:06 -0000 http://perforce.freebsd.org/chv.cgi?CH=149427 Change 149427 by raj@raj_mimi on 2008/09/08 16:03:33 Do not use cached page for temporary mapping in pmap_zero_page_generic() We can safely use a cached page for the temporary mapping only if d-cache write-allocate feature is disabled or not present. The physical page which we zero here is accessed via *additional* kernel mapping for the period of zeroing operation. However with WA enabled we can have modified but unflushed content pertaining to this physical page still in the d-cache due to its primary mapping. In this case when that cached content is flushed it will overwrite [portions of] the physical page we want to zero here. This is a general problem with multiple virtual mappings covering the same physical page with write-allocate d-cache: there is inherent potential for corruptions of this kind, which are not easily resolved; it it best policy that such multiple mappings are not allowed. Affected files ... .. //depot/projects/arm/src/sys/arm/arm/pmap.c#40 edit Differences ... ==== //depot/projects/arm/src/sys/arm/arm/pmap.c#40 (text+ko) ==== @@ -3851,21 +3851,19 @@ mtx_lock(&cmtx); /* - * Hook in the page, zero it, and purge the cache for that - * zeroed page. Invalidate the TLB as needed. + * Hook in the page, zero it, invalidate the TLB as needed. + * + * Note the temporary zero-page mapping must be a non-cached page in + * ordert to work without corruption when write-allocate is enabled. */ - *cdst_pte = L2_S_PROTO | phys | - L2_S_PROT(PTE_KERNEL, VM_PROT_WRITE) | pte_l2_s_cache_mode; - PTE_SYNC(cdst_pte); + *cdst_pte = L2_S_PROTO | phys | L2_S_PROT(PTE_KERNEL, VM_PROT_WRITE); cpu_tlb_flushD_SE(cdstp); cpu_cpwait(); - if (off || size != PAGE_SIZE) { + if (off || size != PAGE_SIZE) bzero((void *)(cdstp + off), size); - cpu_dcache_wbinv_range(cdstp + off, size); - } else { + else bzero_page(cdstp); - cpu_dcache_wbinv_range(cdstp, PAGE_SIZE); - } + mtx_unlock(&cmtx); #endif }