From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 16:42:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F729F89; Tue, 27 Nov 2012 16:42:57 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 0C94D8FC13; Tue, 27 Nov 2012 16:42:56 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 92A504C03B6; Tue, 27 Nov 2012 10:42:49 -0600 (CST) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 910024C02FE; Tue, 27 Nov 2012 10:42:49 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id YP-Ye_oXYpOj; Tue, 27 Nov 2012 10:42:49 -0600 (CST) 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 mh11.mail.rice.edu (Postfix) with ESMTPSA id 8226F4C03A0; Tue, 27 Nov 2012 10:42:47 -0600 (CST) Message-ID: <50B4ED86.40308@rice.edu> Date: Tue, 27 Nov 2012 10:42:46 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> In-Reply-To: <20121127150625.GJ3013@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 27 Nov 2012 16:42:57 -0000 On 11/27/2012 09:06, Konstantin Belousov wrote: > On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >> Fri Nov 23 17:00:40 CET 2012 >> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >> >> #0 doadump (textdump=-2014022336) at pcpu.h:229 >> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >> dummy2=, >> dummy3=, dummy4=) >> at /usr/src/head/sys/ddb/db_command.c:578 >> #2 0xffffffff8033e074 in db_command (last_cmdp=, >> cmd_table=, dopager=1) at >> /usr/src/head/sys/ddb/db_command.c:449 >> #3 0xffffffff8033dd62 in db_command_loop () at >> /usr/src/head/sys/ddb/db_command.c:502 >> #4 0xffffffff80340690 in db_trap (type=, code=0) >> at /usr/src/head/sys/ddb/db_main.c:231 >> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=> out>) >> at /usr/src/head/sys/kern/subr_kdb.c:654 >> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >> at /usr/src/head/sys/amd64/amd64/trap.c:579 >> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >> msg=) >> at cpufunc.h:63 >> #9 0xffffffff8088086f in panic (fmt=) >> at /usr/src/head/sys/kern/kern_shutdown.c:628 >> #10 0xffffffff80adea4a in vm_object_madvise (object=, >> pindex=, end=8952, advise=) >> at /usr/src/head/sys/vm/vm_object.c:1101 >> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >> start=, >> end=, behav=5) at >> /usr/src/head/sys/vm/vm_map.c:2140 >> #12 0xffffffff80adbd8d in sys_madvise (td=, >> uap=) >> at /usr/src/head/sys/vm/vm_mmap.c:752 >> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >> traced=0) at subr_syscall.c:135 >> #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 >> #15 0x00000000016f3bfa in ?? () > I think this is an omission in the check for the object types. BTW, this > pattern already repeats in several places, I thought about adding either > new pager method, like boolean_t vm_pager_is_pageable(), or just a flag > fields to the struct vm_pager to classify the vm objects. A fictitious page should always have a non-zero wire count. In fact, it should always be one and never change. (See vm_page_unwire().) In vm_object_madvise(), there is a check against the page's wire count that precedes the KASSERT(). This check should prevent the KASSERT() from being reached for the various device-backed object types. So, something else has gone wrong here, or rather something has gone wrong elsewhere that caused the KASSERT() failure here. Andre, can we see the contents of the offending struct vm_page and also the struct vm_object to which the offending page belongs to? Also, are you running a kernel with any experimental zero-copy send support? (Kostik, by the way, I would be happy to see attribute flags added to the vm object to take the place of the type checks.) > I am curious, what was the process which caused the panic ? > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index e19750c..5b8ed23 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -1060,7 +1060,10 @@ shadowlookup: > (tobject->flags & OBJ_ONEMAPPING) == 0) { > goto unlock_tobject; > } > - } else if (tobject->type == OBJT_PHYS) > + } else if (tobject->type == OBJT_PHYS || > + tobject->type == OBJT_SG || > + tobject->type == OBJT_MGTDEVICE || > + tobject->type == OBJT_DEVICE) > goto unlock_tobject; > m = vm_page_lookup(tobject, tpindex); > if (m == NULL && advise == MADV_WILLNEED) {