From owner-svn-src-head@FreeBSD.ORG Sat Dec 15 00:21:26 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 AC9B8365; Sat, 15 Dec 2012 00:21:26 +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 7E8AA8FC16; Sat, 15 Dec 2012 00:21:26 +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 B5D041A3CE3; Fri, 14 Dec 2012 16:21:25 -0800 (PST) Message-ID: <50CBC285.7060307@mu.org> Date: Fri, 14 Dec 2012 16:21:25 -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: Robert Watson Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <50C9271C.70803@mu.org> <20121213090215.GP97487@FreeBSD.org> <201212141149.07671.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 15 Dec 2012 02:50:52 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, John Baldwin , svn-src-all@freebsd.org, Alfred Perlstein , Andriy Gapon , Gleb Smirnoff , Navdeep Parhar , 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 00:21:26 -0000 On 12/14/12 4:12 PM, Robert Watson wrote: > On Fri, 14 Dec 2012, John Baldwin wrote: > >> On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote: >>> On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A> >>> The problem again is that not all the KASSERTS are inviolable, if >>> you A> want to do a project to split them, then please do, it would >>> really be A> helpful, as for now, they are a mis-mash of >>> death/warnings and there are A> at least three vendors who approve >>> of this as well as 3 long term A> committers that approved my change >>> (not including Adrian). >>> >>> Can you show examples of not inviolable KASSERTs? >> >> There are none. They are all assertions for a reason. However, in >> my experience at several large consumers of FreeBSD, no one wants to >> run with INVARIANTS in production. Not because we don't want panics >> (believe me, Yahoo! gets plenty of panics even with INVARIANTS >> disabled), but because the performance overhead, and redefining >> INVARIANTS into printf doesn't address that at all. > > In the past, FYI, the two major INVARIANTS hits were un-inlining of > locking, and UMA using additional global locking to perform > heavier-weight sanity checking. For me, at least, the former wasn't > such a problem, but the latter was extremely measurable. I have > occasionally wondered if we should have another option name for > heavier-duty sanity checking, as is the case with WITNESS, > SOCKBUF_DEBUG, etc, so that INVARIANTS overhead can be made tolerable > for more real-world installations. As you observe, our invariants > tests are generally things where you catch critical problems in much > more debuggable states, rather than sources of additional fragility, > and it would be great if we could leave more in so that bug reports > were able to contain more information. > > Robert > Yes. The KTR system offers an interesting reference for a model that allows us to make a compile time decision about which areas to trace. There used to be a DIAGNOSTIC option for the more heavy checks, this is either removed or just not used these days. Again, using a mask like KTR might be a win if we bring back the equivalent of heavy weight DIAGNOSTIC option. Often I've been guilty of putting KASSERT(ptr != NULL) checks into the code too. Those are really just to make it less painful when hitting that bug, so instead of having to do a lot of homework to figure out the fault address and line number, I can just get a pretty printed message under INVARIANTS. Maybe those "pretty null checks" need to go under another option, perhaps DIAGNOSTIC, or another .. ??PRETTY_PANIC. Anyhow, I've always been a huge fan of FreeBSD due the additional debugging checks it offered. I was the one that suggested splassert() back in the day when we would continually find issues with spl calls. Additionally I found doing filesystem work a ton easier with DEBUG_VFS_LOCKS under FreeBSD than under Darwin which at the time did not have such a feature. One of my great joys in developing FreeBSD is the flexibility and power it offers us as developers by giving us a huge library of debugging tools. -Alfred