From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 07:40:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3727416A402 for ; Wed, 20 Feb 2008 07:40:28 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 026EF13C455 for ; Wed, 20 Feb 2008 07:40:27 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id EAEE12C2C71; Wed, 20 Feb 2008 01:23:18 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nBA1mq1rye4o; Wed, 20 Feb 2008 01:23:18 -0600 (CST) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 23B1B2C2C5F; Wed, 20 Feb 2008 01:23:18 -0600 (CST) Message-ID: <47BBD565.9040705@cs.rice.edu> Date: Wed, 20 Feb 2008 01:23:17 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070805 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kostik Belousov References: <20080219132455.GD57756@deviant.kiev.zoral.com.ua> In-Reply-To: <20080219132455.GD57756@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Michiel Boland , freebsd-current@freebsd.org Subject: Re: panic upon starting X in recent -CURRENTs (intel driver) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 07:40:28 -0000 Kostik Belousov wrote: >What happen there is that munmap() do the split for the /dev/mem mapping. >This caused the OBJT_DEVICE ref_count to be bumped, and vm_map_entry_delete() >called vm_object_page_remove(). The later called pmap_remove_all() >unconditionally. > >pmap_remove_all has the KASSERT that fails exactly when supplied >fictitious page. It becomes KASSERT in the rev. 1.106 of i386/pmap.c, >committed 2008/01/08, it was under the PMAP_DIAGNOSTIC before. > >Since such page has md.pv_list empty anyway, this KASSERT seems to be >only the statement of intent. The change below would prevent the panic >by not calling pmap_remove_all from vm_object_page_remove for such pages. > > > In fact, md.pv_list is never initialized for fictitious pages. So, the invocation of pmap_remove_all() has only worked 'til now because the underlying memory is zeroed. >Alan, do you have objections ? [Alternative seems to be a removal of the >assertions from all pmap implementations, that also weaken the invariants >for other callers that do skip fictitious pages]. > > I want to think this over. I'll e-mail you this weekend. >diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >index 21c0ac6..21ee10d 100644 >--- a/sys/vm/vm_object.c >+++ b/sys/vm/vm_object.c >@@ -1884,7 +1884,8 @@ again: > */ > if ((wirings = p->wire_count) != 0 && > (wirings = pmap_page_wired_mappings(p)) != p->wire_count) { >- pmap_remove_all(p); >+ if ((p->flags & PG_FICTITIOUS) == 0) >+ pmap_remove_all(p); > /* Account for removal of managed, wired mappings. */ > p->wire_count -= wirings; > if (!clean_only) >@@ -1898,7 +1899,8 @@ again: > if (p->valid & p->dirty) > continue; > } >- pmap_remove_all(p); >+ if ((p->flags & PG_FICTITIOUS) == 0) >+ pmap_remove_all(p); > /* Account for removal of managed, wired mappings. */ > if (wirings != 0) > p->wire_count -= wirings; > >