From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:39:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F34571065697 for ; Fri, 8 Oct 2010 17:39:55 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id C22308FC18 for ; Fri, 8 Oct 2010 17:39:55 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id DC2F328F731; Fri, 8 Oct 2010 12:39:54 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id DkRi+1so3B7V; Fri, 8 Oct 2010 12:39:54 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 7EF3628F6F1; Fri, 8 Oct 2010 12:39:53 -0500 (CDT) Message-ID: <4CAF5768.4020605@rice.edu> Date: Fri, 08 Oct 2010 12:39:52 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Kurt Alstrup References: <4CAC14DA.7050409@verizon.net> <4CADFD60.9040005@rice.edu> <4CAF4D64.4050105@frontier.com> In-Reply-To: <4CAF4D64.4050105@frontier.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:39:56 -0000 Kurt Alstrup wrote: > Apologies for late response, wanted to check the code again. > > > On 10/07/2010 10:03 AM, Alan Cox wrote: > >> Alan Cox wrote: >> At a high-level, I agree with much of what you say. In particular, if >> pmap_enter() is applied to a virtual address that is already mapped by a large >> page, the reported panic could result. However, barring bugs, for example, in >> memory allocation by the upper levels of the kernel, the panic inducing >> situation shouldn't occur. >> > Calls to malloc() of items larger than a page takes a turn through UMA and > eventually ends up in kmem_malloc() via its page_alloc() routine. > Kmem_malloc() in turn gets the pages from vm_page_alloc(), parks them in > the kmem_object and maps them into the kernel_pmap in a loop callings > pmap_enter() for each page. The assigned VA's are pulled from kmem_map. > Pages acquired through vm_page_alloc() may be backed by a super page > reservation and thus are eligible for auto-promotion. > > Calls to free() initially take a similar route, ending up on kmem_free() > via UMAs page_free() routine. From there the call path is vm_map_remove(), > vm_map_remove(), vm_map_delete() to pmap_remove(). > > This logic indicate, that from the kernel/vm perspective the malloc/free() > pair will map/unmap pages as needed. However, the pmapper never unmaps > these pages as far as I can tell. The call path is pmap_remove(), > pmap_remove_pte() to pmap_unuse_pt() who ignores the removal because the > VA >= VM_MAXUSER_ADDRESS. > > No, consider: static int pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va, pd_entry_t ptepde, vm_page_t *free) { pt_entry_t oldpte; vm_page_t m; PMAP_LOCK_ASSERT(pmap, MA_OWNED); oldpte = pte_load_clear(ptq); pte_load_clear() zeroes the PTE, regardless of whether it is a kernel or user PTE. I'm afraid that I need to catch an airplane. I'll follow up to the rest of your message later. Regards, Alan