From owner-svn-src-all@FreeBSD.ORG Wed Dec 12 18:47: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 C949765A; Wed, 12 Dec 2012 18:47:25 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6AF8FC0A; Wed, 12 Dec 2012 18:47:25 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 3EEF51A3CC0; Wed, 12 Dec 2012 10:47:25 -0800 (PST) Message-ID: <50C8D13C.6070107@mu.org> Date: Wed, 12 Dec 2012 10:47:24 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> In-Reply-To: <201212121046.43706.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , src-committers@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: Wed, 12 Dec 2012 18:47:25 -0000 to all: I am trying to take this offline with John so that we can discuss the reasoning behind the change and come to an agreement on how it is implemented, or if not to remove it. -Alfred On 12/12/12 7:46 AM, 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. >