From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 08:48:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1570F4E2; Sat, 14 Jun 2014 08:48:53 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7462C14; Sat, 14 Jun 2014 08:48:52 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id bs8so1922334wib.13 for ; Sat, 14 Jun 2014 01:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qpu+clM1dT81xXfnoK4B7Qz5/9oLnokvYDUdTA0s6K8=; b=ny3Qx0kZGJ5R2jDlaFJW55w2lxytJiTPZgQxOlB5n5+zsl8rm0o8SI76RvPC9RMdb1 f1108YyH8aVD7LTSn3+ytSxSDcfWrNfZCoFD0e7jLm0r+HyQAZ01LzV8FtPWmgP9Sxlw dH87iXdB2QAzSKN+ifPz/yqIPFA2Ju6fHBEM7/cVzy0HxopVWV5LPB8zbqH5dkN40aK+ ptB15WAFIeJlI3sh1WrpTgn4yK9rvpks1bGRTT4Vdx6QbTZMFp1LBF8cBMWR4D6r0/wn m38Xlw4V41fusB+fW4QRHRYj2ucFvHOSOn2rHc5YbD+H/5TPx/mO3rM61z7KdWxub4Jf OllQ== X-Received: by 10.194.93.228 with SMTP id cx4mr11199162wjb.61.1402735730782; Sat, 14 Jun 2014 01:48:50 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id bq7sm1692091wib.7.2014.06.14.01.48.49 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 14 Jun 2014 01:48:50 -0700 (PDT) Date: Sat, 14 Jun 2014 10:48:47 +0200 From: Mateusz Guzik To: Darren Reed Subject: Re: FreeBSD 10.0 adaptive mutex with strange mtx_lock value = panic Message-ID: <20140614084847.GA8122@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Darren Reed , freebsd-hackers@freebsd.org References: <539BFEC4.1020103@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <539BFEC4.1020103@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:48:53 -0000 On Sat, Jun 14, 2014 at 05:50:28PM +1000, Darren Reed wrote: > In debugging a kernel panic running inside a VM, I found the following: > > (kgdb) p *$15 > $16 = {lock_object = {lo_name = 0xffffffff81a8a224 "filter rule lock", > lo_flags = 16908288, lo_data = 0, lo_witness = 0x0}, mtx_lock = 6} > > 16908288 = 0x1020000 (CLASS=1|LO_WITNESS) > > While everything "looks" normal, mtx_lock = MTX_UNOWNED|MTX_CONTESTED > > And kern_mutex.c cannot deal with that. > > This is 100% repeatable/reproducible ... > > Am I dealing with a VM bug or a FreeBSD bug? > This is a 'destroyed mutex' state, i.e. you are doing mtx_lock after mtx_destroy. A kernel with INVARIANTS enabled wold tell you that straight away. -- Mateusz Guzik