From owner-svn-src-head@FreeBSD.ORG Wed Dec 12 22:11: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 3458ABF9; Wed, 12 Dec 2012 22:11:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 021088FC14; Wed, 12 Dec 2012 22:11:20 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 60E24B91E; Wed, 12 Dec 2012 17:11:19 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: svn commit: r244112 - head/sys/kern Date: Wed, 12 Dec 2012 16:58:48 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212121658.49048.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 12 Dec 2012 17:11:19 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , src-committers@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: Wed, 12 Dec 2012 22:11:20 -0000 On Wednesday, December 12, 2012 12:06:22 pm Adrian Chadd wrote: > 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. Hmmm, I'll have to chew on this. Adding lots of returns because panic's are now no longer dead2 was why I ended up backing the removal of the RESTARTABLE_PANICS option. I'm inclined to say that it's really bad to let a kernel known to be in a bad state continue, and that if someone has asked for the slowdown of all the extra checks INVARIANTS adds, they might as well minimize the chance for data corruption by having the kernel stop as soon as a problem is detected. (Note that the primary reason I know for people not running with INVARIANTS enabled is not that they don't want panics, but that they don't want the performance hit.) -- John Baldwin