From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 20:52:05 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 6F158511 for ; Sat, 22 Nov 2014 20:52:05 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 0CA081FD for ; Sat, 22 Nov 2014 20:52:04 +0000 (UTC) X-AuditID: 1209190f-f79b36d0000037ef-89-5470f76df574 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 53.93.14319.D67F0745; Sat, 22 Nov 2014 15:51:57 -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 sAMKpudk005209; Sat, 22 Nov 2014 15:51:57 -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 sAMKpstx019119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Nov 2014 15:51:56 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAMKps9B004268; Sat, 22 Nov 2014 15:51:54 -0500 (EST) Date: Sat, 22 Nov 2014 15:51:54 -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: <546FA1DD.2070109@panasas.com> Message-ID: References: <546BA9D3.6070007@panasas.com> <546BF3F5.8030109@panasas.com> <546FA1DD.2070109@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+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrZv7vSDEYMkGBYsTG1sYLea8+cDk wOQx49N8Fo/bx+exBjBFcdmkpOZklqUW6dslcGWsXLeCreAoX8W6m79YGxifcXcxcnJICJhI PNnygBHCFpO4cG89WxcjF4eQwGwmifV7z7NAOBsZJXYv/8ME4Rxikph1ZQEzhNPAKLF1xgoW kH4WAW2JmU+3sILYbAIqEjPfbGQDsUUE9CTO9fSAxZkF5CX+X7nMBGILC9hIfLiwHayXE6j3 +ZdNYPW8Ao4Sk080QW2bxyhxedkXsGZRAR2J1funsEAUCUqcnPmEBWKolsTy6dtYJjAKzkKS moUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwuEry72D8dlDpEKMA B6MSD6/DgoIQIdbEsuLK3EOMkhxMSqK8Tp+BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4dXqA crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxvvwI1ChalpqdWpGXm lCCkmTg4QYbzAA23+AYyvLggMbc4Mx0if4pRUUqctwGkWQAkkVGaB9cLSyevGMWBXhHmTQFp 5wGmIrjuV0CDmYAG/12aCzK4JBEhJdXAqOvU/+zl7kVNwS9Yvl0/n1vMuEox6G/34xd3N1Ud /P240SR7/cXq+UnJXokfV6mcnFsy90T6Ts/iTy8YnXcmzNVsN+HI2SVU1lN/Xz9UnJv1Rv+z azaCFhFva1RL9sypVz3X9J534j/nW3PkiisM+Vcwbsm/2S+58QGfPSPfvvdG+/YrfYzaq8RS nJFoqMVcVJwIANgmfAYCAwAA 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: Sat, 22 Nov 2014 20:52:05 -0000 On Fri, 21 Nov 2014, Ellis H. Wilson III wrote: > Before I start, and this is mainly geared to my responder Benjamin Kaduk, > based on your response, are you suggesting that the cnputc WITNESS panic you > expected to happen is now completely unavoidable in FreeBSD 10? I.E., is this > a spinlock that WITNESS falls over each time but that is provably deadlock > free that the developers have decided cannot be BLESSED for some reason? https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031316.html looks to be a better explanation than the previous link I sent ... in short, console output is hard. > I guess I just can't wrap my head around why we would ever move to a regime > where SKIPSPIN is the default for testing... That just seems like an open > invitation for introducing spinlock regressions. I don't think anyone made the conscious decision to do that, it just happened by default as no one spent the time to fix the aforementioned issue. > Moving onto the LORs I'm seeing, a question I have as a newbie to WITNESS > debugging is how exactly to interpret the output if I see a stacktrace and > then a LOR output like the following: > > lock order reversal: > 1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @ > /usr/src/sys/dev/random/random_harvestq.c:198 > 2nd 0xffffffff813b6208 scrlock (scrlock) @ > /usr/src/sys/dev/syscons/syscons.c:2682 > > Does this mean WITNESS has already stored an ordering of #1 harvest_mtx then > #2 scp->scr_lock, and somewhere somebody tried to lock scp->scr_lock without > first getting harvest_mtx? Or the reverse (WITNESS previously recorded > scrlock and then harvest and the lines it spit out were the offenders?) I believe it is the latter (the ordering being printed is the bad one which caused WITNESS to complain). -Ben