From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:39:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A027256E for ; Tue, 18 Nov 2014 22:39:24 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FBA0DD0 for ; Tue, 18 Nov 2014 22:39:23 +0000 (UTC) X-AuditID: 1209190e-f79696d000006c87-79-546bca943aa4 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 56.93.27783.49ACB645; Tue, 18 Nov 2014 17:39:16 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sAIMdFVX025263; Tue, 18 Nov 2014 17:39:15 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAIMdDwK004723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2014 17:39:15 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAIMdD69011280; Tue, 18 Nov 2014 17:39:13 -0500 (EST) Date: Tue, 18 Nov 2014 17:39:13 -0500 (EST) From: Benjamin Kaduk To: "Ellis H. Wilson III" Subject: Re: WITNESS observes 2 LORs on Boot of Release 10.1 In-Reply-To: <546BA9D3.6070007@panasas.com> Message-ID: References: <546BA9D3.6070007@panasas.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrTvlVHaIweqXfBYnNrYwWsx584HJ gcljxqf5LB63j89jDWCK4rJJSc3JLEst0rdL4MrYefgmS8F//opNO46xNzB+5Oli5OSQEDCR 6Fz2nQ3CFpO4cG89kM3FISQwm0ni0O9tUM5GRomze69COYeYJDa2XGWEcBoYJX4+vccK0s8i oC2x+sxfJhCbTUBFYuabjWBzRQT0JM719IDVMAvIS/y/chmsRljARuLDhe0sIDYnUO+xb28Z QWxeAUeJGZMOMYPYQgJaEg+mrwCbIyqgI7F6/xQWiBpBiZMzn7BAzNSSWD59G8sERsFZSFKz kKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECA5WSb4djF8PKh1iFOBg VOLhTZyaFSLEmlhWXJl7iFGSg0lJlFfhaHaIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFewW6g HG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBK/9SaBGwaLU9NSKtMyc EoQ0EwcnyHAeoOFRIDW8xQWJucWZ6RD5U4yKUuK8H44DJQRAEhmleXC9sGTyilEc6BVhXiOQ dh5gIoLrfgU0mAlo8JwNmSCDSxIRUlINjAmPMqeb8n6/Gfsk8c3qwjtzdHaqy7yRsr4flBx1 2sE2hs2ZI37npjuFqUtOFj1b7ypmbnlnzu6b9WJPfdZ/T3h2d8Wh1imtDYc7Vni0ZBdNs1Sb 4qXd7zcnJ7jU4/lbJd87zIWvbOw/9S2udJv3LCCyOvFzZuTxr0ua71S9O8vpnPBEJjVyjxJL cUaioRZzUXEiAAigHgEBAwAA Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 22:39:24 -0000 On Tue, 18 Nov 2014, Ellis H. Wilson III wrote: > This is on a virtual machine via VirtualBox, but we have reproduced it on real > hardware. Regarding the latter reversal, I have dug in the code and see the > calls go about in the following order: > > In sys/dev/random/random_harvestq.c: > 198 mtx_lock_spin(&harvest_mtx); > 209 msleep_spin_sbt(&random_kthread_control, &harvest_mtx, > Now in sys/kern/kern_synch.c: > 297 sleepq_lock(ident); > Now in sys/kern/subr_sleepqueue.c > 237 mtx_lock_spin(&sc->sc_lock); > > The above line numbers might be a hair off from head since I'm looking at code > synced last week. > > I'm happy to open a bug on this if that's the desirable course of action, or > to even assist in fixing it, but I wanted to first see if anybody knew about > these already (they didn't show up on the known LORs list on quick perusal) or > if this was simply a case of WITNESS being overly conservative and throwing > false positives. If this belongs on a different list just let me know. I don't believe it is known, and this list is fine. > I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0 > and I was tracking current, hoping they would go away by 10.1, but it seems > they persist as shown below. I suspect this is because current is being built > with WITNESS on but also with SKIPSPIN on. So these issues are unlikely to > show up for any devs but those who specifically enable WITNESS and disable > SKIPSPIN like myself. At my work we would greatly like to do our debugging > with checking of spin-locking order included and panicing upon LOR detection. > That's not possible with these in existence. However, I was under the impression that a kernel built with WITNESS and without WITNESS_SKIPSPIN would panic on boot on the cnputs_mutx (see, e.g., https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076864.html). So, (1) I'm surprised you can boot it, and (2) that would explain why no one else has been using it. -Ben