From owner-svn-src-all@FreeBSD.ORG Thu Dec 13 06:51:25 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80A247C5; Thu, 13 Dec 2012 06:51:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 986C88FC0A; Thu, 13 Dec 2012 06:51:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA11190; Thu, 13 Dec 2012 08:51:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tj2dd-000Mmz-6U; Thu, 13 Dec 2012 08:51:21 +0200 Message-ID: <50C97AE8.1040806@FreeBSD.org> Date: Thu, 13 Dec 2012 08:51:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <201212121658.49048.jhb@freebsd.org> <50C904B8.6000502@mu.org> <50C90641.4030000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , John Baldwin , svn-src-all@FreeBSD.org, Alfred Perlstein , src-committers@FreeBSD.org, svn-src-head@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 06:51:25 -0000 on 13/12/2012 00:43 Adrian Chadd said the following: > On 12 December 2012 14:33, Andriy Gapon wrote: > >>> Yes, two of my employers were more of "we want to get more debug metrics, we >>> have the spare cycles, but we can't deal with superfluous panics". >>> >>> It also allows us "non-architects" to slip in a debug image when we have spare >>> cpu without getting yelled at for "crashing the $foo". >> >> There is clearly something wrong with this sort of mentality. >> >> If you find instances where a developer put panic(9) (or KASSERT or etc) to mean >> "maybe here is a bug, let's just panic", then let's get those things fixed. >> >> But most of assertions in our code that are know to me really mean that a real >> bug has already occurred, that portions of kernel state are corrupted and there >> is no going back to a sane state, only going forward to corrupting more and more. > > Dude, if you're running -STABLE right now, you don't have invariants > enabled and you aren't checking for them. > So right now, as it stands, large swaths of our kernel code are > falling afoul of what you're calling Alfred out on. Pal, it's because there are people who thoroughly and regularly test code with INVARIANTS that the code with or without INVARIANTS does not crash as often as it could. When I tested the code with INVARIANTS I trust it to run without those and if a user get a mystery panic one of the first things to advise is to enable various debugging options. > Before you all reply, please review and understand the difference > between "panic()" and "KASSERT()". panic() is not being changed here. > KASSERT() is what's being changed here. panic() is not optional. > KASSERT() is. With a non-INVARIANTS kernel, we _are not checking > invariants_ and we are continuing to run _after_ said non-compiled-in > invariants. With this in mind, please re-review this. :-) KASSERT is not optional contrary to your opinion. We elect to not compile it in for performance reasons, but it is not optional when it is compiled in. -- Andriy Gapon