From owner-svn-src-head@FreeBSD.ORG Wed Dec 12 22:37:35 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 6F415E7D; Wed, 12 Dec 2012 22:37:35 +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 AE2408FC0A; Wed, 12 Dec 2012 22:37:33 +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 AAA07324; Thu, 13 Dec 2012 00:37:32 +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 1Tiuvj-000MRZ-Ns; Thu, 13 Dec 2012 00:37:31 +0200 Message-ID: <50C9072A.6040605@FreeBSD.org> Date: Thu, 13 Dec 2012 00:37:30 +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> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Alfred Perlstein , src-committers@FreeBSD.org, John Baldwin 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: Wed, 12 Dec 2012 22:37:35 -0000 on 12/12/2012 19:06 Adrian Chadd said the following: > kassert()s are already optional. Ie, you can choose to not compile them in. > > So the __dead2() code path bit for doing KASSERT() -> kassert_panic() > at compile time isn't a problem. > > The problem is where you do panic() -> kassert_panic() (eg in the > Witness code) which is what Alfred discovered shortly after doing up > his initial patch. > > Anything which is a KASSERT() can and should be treated as a run-time > warning just as much as a run-time "crash here so I can figure out > what broke." Having the warning in a production box is going to be > helpful for developers. I have a quite different view on purpose and costs of KASSERTs. Specifically referring to r243980 I do not think that "non-fatal asserts" should really exist (or do exist). I wish all this muddying of KASSERT meaning would get reverted. These quite sensitive changes were rushed in, IMO. > On 12 December 2012 07:46, John Baldwin wrote: >> On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: >>> Author: alfred >>> Date: Tue Dec 11 07:08:14 2012 >>> New Revision: 244112 >>> URL: http://svnweb.freebsd.org/changeset/base/244112 >>> >>> Log: >>> Cleanup more of the kassert_panic. >>> >>> fix compile warnings on !amd64 and NULL derefs that would happen >>> if kassert_panic() would return. >> >> This is one reason why having kassert not panic is such a bad idea. There are >> tons of places where the compiler knows that panic() is __dead2, and there is >> no cleanup code to handle what happens when an invariant is violated. This is >> not safe to run in the field unless your customers do not care about their >> data. If you are interested in doing regression tests, I am using a very >> different approach for some locking regression tests I am working on in p4 >> that allow you to use a wrapper around setjmp/longjmp to "catch" panics >> somewhat like exception handling in C++/Java (though much cruder). However, >> evne that is only intended for testing, not for production cases where >> production data is at stake. >> >> -- >> John Baldwin -- Andriy Gapon -- Andriy Gapon