svn commit: r244112 - head/sys/kern

[Alfred Perlstein]

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