From owner-svn-src-head@FreeBSD.ORG Thu Dec 13 00:25:20 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0184454F; Thu, 13 Dec 2012 00:25:19 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 947858FC0A; Thu, 13 Dec 2012 00:25:19 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so431529dad.13 for ; Wed, 12 Dec 2012 16:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UHwUG6hI/dDfVeR49brYDFf/hLSpb0gLjQ42DJQNgKM=; b=b1/On5VBYpYZUSI7i4BdegJjySWGh44Wj2/pZ7o0/Fd35thpN70Csv/T1gVbyyzodM nyDe+TVMAFa/l4ux7XCEJG/xhe64gd9N1oSYQa/ijRv7hsx6XcQyKwWB2Vsl/fCENTZw suP2S3u/3yjHlg4b57WjUVPnNhhMTBmw3GUPZYgrGt/EDZfP2DM31+hvg/Rwyp1CRfsp yt//dMJsHhtj5cUeMWRPCQV8hq3XNUEhALyWYofDwVDpeIKqUfagGVcc/6WjdlBhw03P IQzzKkE+eHZMuRJ18l9cBsmf7HCHwieooc3iEHvkUdIRsXtqGo++wa8Ne/mzhbbBvKdD kY4w== Received: by 10.68.143.162 with SMTP id sf2mr7383810pbb.137.1355358318945; Wed, 12 Dec 2012 16:25:18 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id ol4sm7623276pbb.58.2012.12.12.16.25.17 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 16:25:18 -0800 (PST) Sender: Navdeep Parhar Message-ID: <50C9206D.6080502@FreeBSD.org> Date: Wed, 12 Dec 2012 16:25:17 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <201212121658.49048.jhb@freebsd.org> <50C90567.8080406@FreeBSD.org> <50C909BD.9090709@mu.org> <50C91B32.4080904@FreeBSD.org> <50C91CD3.7030900@mu.org> In-Reply-To: <50C91CD3.7030900@mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@FreeBSD.org, John Baldwin , svn-src-all@FreeBSD.org, Alfred Perlstein , Andriy Gapon , svn-src-head@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:25:20 -0000 On 12/12/12 16:09, Alfred Perlstein wrote: > On 12/12/12 4:02 PM, Navdeep Parhar wrote: >> On 12/12/12 14:48, Alfred Perlstein wrote: >>> On 12/12/12 2:29 PM, Andriy Gapon wrote: >>>> Now we get a new middle-ground: get both worse performance (because >>>> KASSERTs are compiled in) and a risk of harming your data (because >>>> KASSERTs no longer panic). The upside: there is no panic! There's just >>>> a log message (or etc). and chance to get more log messages because >>>> the insanity propagates. And a chance to lose your data (your >>>> customer's) - but I've already mentioned this. I am not sure that I >>>> like this kind of middle-ground. >>> I have a number of points here: >>> >>> The most important one being: >>> 1) without kassert you would still have the bug, just that it would be >>> unreported. >>> The upside: there is no panic! There's **NO** log message (or etc). >>> and chance to get more log messages because the insanity propagates. >>> >>> Terrible! >>> >>> Let me explain that again: >>> If you don't compile in KASSERT, then it's not like the condition is >>> never going to happen. Instead it will just be unreported. >> A KASSERT() really is for a condition that should never happen. It is >> primarily useful during development and testing (and when the code is >> reworked or redesigned). I agree with Andriy here -- a non-fatal assert >> shouldn't really exist. > > > What do you think happens to a FreeBSD kernel when INVARIANTS is > compiled in and it trips an assertion after my change? I know the new knob has sane defaults. My point was that invariants should be considered inviolable. A knob that allows for it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their meaning, so it may have been better to introduce a new macro for the kind of tests you had in mind. I would use it too instead of the if (!foo) kdb_backtrace() that I often resort to for conditions that I'm not sure about. Regards, Navdeep