From owner-svn-src-head@FreeBSD.ORG Wed Mar 19 16:31:23 2014 Return-Path: Delivered-To: svn-src-head@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 162C272C; Wed, 19 Mar 2014 16:31:23 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C870ED28; Wed, 19 Mar 2014 16:31:22 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s2JGRSEp021003; Wed, 19 Mar 2014 11:31:21 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1jqcvc03r6-1; Wed, 19 Mar 2014 11:31:20 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 428F0500152; Wed, 19 Mar 2014 11:31:20 -0500 (CDT) Message-ID: <5329C657.3000705@rice.edu> Date: Wed, 19 Mar 2014 11:31:19 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John-Mark Gurney , Adrian Chadd Subject: Re: svn commit: r263214 - in head/sys: compat/freebsd32 kern sys References: <201403160053.s2G0rfmA073668@svn.freebsd.org> <20140316012609.GY32089@funkthat.com> In-Reply-To: <20140316012609.GY32089@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403190076 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 16:31:23 -0000 On 03/15/2014 20:26, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Mar 15, 2014 at 18:17 -0700: >> How far along does it get? > It rarely gets to multiuser, and even if it does, it panics very > shortly afterward: > panic: vm_page_alloc: page 0xc0805db0 is wired > > I did finally get around to dumping the vm_page struct for it (the > CTF crazyness) and I did send it to alc and kib, but neither one has > replied... > > here is a dump in case someone else has some vm_page clue: > {'act_count': '\x00', > 'aflags': '\x00', > 'busy_lock': 1, > 'dirty': '\xff', > 'flags': 0, > 'hold_count': 0, > 'listq': {'tqe_next': 0xc0805e00, 'tqe_prev': 0xc06d18a0}, > 'md': {'pv_kva': 3235856384, > 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc0805de0}, > 'pv_memattr': '\x00', > 'pvh_attrs': 0}, > 'object': 0xc06d1878, > 'oflags': '\x04', > 'order': '\t', > 'phys_addr': 17776640, > 'pindex': 3572, > 'plinks': {'memguard': {'p': 0, 'v': 3228376932}, > 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06d1f64}, > 's': {'pv': 0xc06d1f64, 'ss': {'sle_next': 0x0}}}, > 'pool': '\x00', > 'queue': '\xff', > 'segind': '\x01', > 'valid': '\xff', > 'wire_count': 1} > > and as you can see, wire_count is not 0... but looks resonable... There are several things wrong with this page. Two lines later, this assertion would also fail: KASSERT(m->dirty == 0, ("vm_page_alloc: page %p is dirty", m)); because a page in the cache/free lists should never be dirty. The page's flags field doesn't include PG_CACHED. So, the object field should be NULL and the valid field should be 0, but they are not. All of these fields are (explicitly) cleared when a page is freed (cf. vm_page_free_toq()). Can you determine if the value of the object field matches the address of either kernel_object or kmem_object? The oflags field containing VPO_UNMANAGED makes that likely. In a nutshell, this looks like the same page is simultaneously in use by one part of the kernel and free in another part. I doubt that it's a simple case of use after free. In that case, the dirty, object, and valid fields would be zero, and the crash would be in a different part of the kernel. > So, I'm blocked until someone w/ clue tells me what more I need to do > to debug this... >