From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:56:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3CBF29D for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id A537B8FC14 for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2409833oag.13 for ; Thu, 15 Nov 2012 09:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Q8SFrS7WLIfT9llpZ/gg0GR2wFSWpUMEED98gONNncI=; b=L4oHlgxKV/uYmCGap7vFNxxc9yj8pf1wPMQ/E0rFSoRPkAlCpEdjYDnGRjSqucEoFr OgwrlB9HXn33zD+MgtvJsuI677U+uKobP2tUBRFI3x3EwUf3jJmbEpl8TYQPJjN5PyBr P0M8vt1Uh+eCa3sZ9BIpumOictAkpy2Q6W0mig1f32IzN48xguZeEnMmvlNyw6zeOA0O JZJnyELCb1zG3ODmzOiLHAWbrxXYeYFWlwAJfXQ3auwSB1NmnlabHofQxk8H1gbsSxes OCJIKNa+UIvG8a/M9dKJW6WtVDt1oMz/hwu34HS75q98M7yd6b5b0RI92kQBXwgNd4Gh 1hvQ== Received: by 10.60.10.133 with SMTP id i5mr1574894oeb.11.1353002182724; Thu, 15 Nov 2012 09:56:22 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id m8sm12902611oeb.3.2012.11.15.09.56.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 09:56:21 -0800 (PST) Sender: Warner Losh Subject: Re: [RFQ] make witness panic an option Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 15 Nov 2012 10:56:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> To: attilio@FreeBSD.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmSwLPuMypES8ja2cHJ1nzIsffgVbdDtBnp+r8cH7mCpLt82C6AKIRmmKwU8cbD7QZF/Rnh Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:56:24 -0000 On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > On 11/15/12, Ian Lepore wrote: >> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>> Hi all, >>>=20 >>> When debugging and writing wireless drivers/stack code, I like to >>> sprinkle lots of locking assertions everywhere. However, this does >>> cause things to panic quite often during active development. >>>=20 >>> This patch (against stable/9) makes the actual panic itself >>> configurable. It still prints the message regardless. >>>=20 >>> This has allowed me to sprinkle more locking assertions everywhere = to >>> investigate whether particular paths have been hit or not. I don't >>> necessarily want those to panic the kernel. >>>=20 >>> I'd like everyone to consider this for FreeBSD-HEAD. >>>=20 >>> Thanks! >>=20 >> I strongly support this, because I'm tired of having to hack it in by >> hand every time I need it. >>=20 >> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >> without a LOR very early in the boot. Once you get past that, 2 or 3 >> device drivers I use panic way before we even get to mounting root. >> Those panics can clearly be ignored, because we've been shipping >> products for years based on this code. (It's on my to-do list to fix >> them, but more pressing problems are higher on the list.) >=20 > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. >=20 > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? >=20 >> When a new problem crops up that isn't harmless, it totally sucks = that I >> can't just turn on witness without first hacking the code to make the >> known problems non-panicky. >=20 > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". >=20 > Can you please make real examples? It sounds like he's more worried about introducing LoRs into his = wireless code. They are harmless, for him, and he can fix them by = reloading the driver. They are only harmful if he loses a race. Warner=