From owner-svn-src-head@FreeBSD.ORG Sat Dec 15 07:50:54 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 16B4C626; Sat, 15 Dec 2012 07:50:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B5DB28FC0A; Sat, 15 Dec 2012 07:50:53 +0000 (UTC) Received: from JRE-MBP-2.local (ppp121-45-232-233.lns20.per1.internode.on.net [121.45.232.233]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id qBF7omXh007186 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 23:50:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50CC2BD2.9010601@freebsd.org> Date: Sat, 15 Dec 2012 15:50:42 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <50C9072A.6040605@FreeBSD.org> In-Reply-To: <50C9072A.6040605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@freebsd.org, John Baldwin , svn-src-all@freebsd.org, Alfred Perlstein , 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: Sat, 15 Dec 2012 07:50:54 -0000 On 12/13/12 6:37 AM, Andriy Gapon wrote: > 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. having worked in a place where asserts were by default NON fatal, I can say that it is a REALLY BAD IDEA. it never did anything but cost us time and effort.. one reason it was there was the lack of a debugger in Linux at the time but all ports had top pay the price... (new linux does have one at last) > > >> 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 >